This is the mail archive of the cygwin mailing list for the Cygwin project.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: rm -rf cannot delete the upmost directory level anymore on a Novell share

On Oct 20 16:57, Franz Sirl wrote:
> Am 2011-10-20 11:46, schrieb Corinna Vinschen:
> >On Oct 20 11:20, Corinna Vinschen wrote:
> >>Anyway, we're not a single step further.  First of all, please send
> >>the FS information I requested above.  Next, please generate straces
> >>of rm 7.0 and rm 8.4 for this scenario, both on the same machine
> >>and running the latest Cygwin developer snapshot and send the full
> >>straces here.
> >
> >Hang on, I'm just creating a patch to improve the debug output of
> >unlink_nt.  I'll upload a new snapshot shorty.
> Here are the complete traces (well, environment and some user id
> info deleted) with the 20111020 snapshot. With rm-7.0 and rm-8.4
> (from coreutils-8.4-2).

Thank you.  Right now this looks like a bug in NWFS.  I discussed this
problem with Eric, our coreutils maintainer, and the strace in the 8.4
case shows that basically the following happens:

  open (lev1) --> fd 3

    This open call opens lev1 for GENERIC_READ, with the sharing mode

      fhandler_base::open: 0 = NtCreateFile (0x704, 80100000, \??\J:\FRA\test_rm_rf\lev1, io, NULL, 0, 7, 1, 4020, NULL, 0)

  fdopendir (3)
  fcntl (3, F_DUPFD) -> fd 4

    This duplicates the descriptor.  Internally that's a DuplicateHandle
    with DUPLICATE_SAME_ACCESS.  Note that a duplicated handle refers to
    the same internal file object.  The new handle points to the same
    file information and thus should not be able to change the sharing mode.

  closedir (3)
  [handle lev2 and lev3]
  rmdir ("lev1")

At this point, unlink_nt is called with the duplicated fd 4 still open:

- unlink_nt tries to open lev1 for DELETE with the sharing mode set to

    unlink_nt: Sharing violation when opening \??\J:\FRA\test_rm_rf\lev1
  This fails with STATUS_SHARING_VIOLATION, but this is expected.  Now
  Cygwin knows that the file is still opened elsewhere.

- Consequentially unlink_nt tries to open the file for DELETE again, but
  this time with the sharing mode set to FILE_SHARE_VALID_FLAGS.  And
  what happens?

    unlink_nt: Opening \??\J:\FRA\test_rm_rf\lev1 for delete failed, status = 0xC0000043

  Again, STATUS_SHARING_VIOLATION.  This doesn't make sense.  The only
  open descriptor, fd 4 refers to a file object which allows sharing for
  deletion.  So, why does this produce a sharing violation?

So, in theory, the following simple testcase should show the same behaviour:

$ cat > stc.c <<EOF
#include <stdio.h>
#include <string.h>
#include <errno.h>
#include <fcntl.h>
#include <sys/stat.h>
#include <sys/types.h>

main ()
  int fd1, fd2;

  if (mkdir ("lev1", 0700) < 0)
      fprintf (stderr, "mkdir: %s\n", strerror (errno));
      return 1;
  fd1 = open ("lev1", O_RDONLY);
  if (fd1 < 0)
      fprintf (stderr, "open: %s\n", strerror (errno));
      return 1;
  fd2 = dup (fd1);
  if (fd2 < 0)
      fprintf (stderr, "dup: %s\n", strerror (errno));
      return 1;
  if (close (fd1) < 0)
      fprintf (stderr, "close(fd1): %s\n", strerror (errno));
      return 1;
  if (rmdir ("lev1") < 0)
      fprintf (stderr, "rmdir: %s\n", strerror (errno));
      return 1;
  if (close (fd2) < 0)
      fprintf (stderr, "close(fd2): %s\n", strerror (errno));
      return 1;
  return 0;
$ gcc -g -o stc stc.c
$ ./stc

It works on NTFS, but if the observation is correct, it should
fail on NWFS.  Can you try it, please?


Corinna Vinschen                  Please, send mails regarding Cygwin to
Cygwin Project Co-Leader          cygwin AT cygwin DOT com
Red Hat

Problem reports:
Unsubscribe info:

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]