X-Recipient: archive-cygwin AT delorie DOT com
X-Spam-Check-By: sourceware.org
Date: Thu, 20 Oct 2011 19:23:53 +0200
From: Corinna Vinschen <corinna-cygwin AT cygwin DOT com>
To: cygwin AT cygwin DOT com
Subject: Re: rm -rf cannot delete the upmost directory level anymore on a Novell share
Message-ID: <20111020172353.GC13505@calimero.vinschen.de>
Reply-To: cygwin AT cygwin DOT com
Mail-Followup-To: cygwin AT cygwin DOT com
References: <4E9EE8CC DOT 5090806 AT lauterbach DOT com> <20111019154540 DOT GE22809 AT calimero DOT vinschen DOT de> <4E9EFE31 DOT 20809 AT lauterbach DOT com> <20111020092033 DOT GA5988 AT calimero DOT vinschen DOT de> <20111020094618 DOT GB5988 AT calimero DOT vinschen DOT de> <4EA036D1 DOT 2020004 AT lauterbach DOT com>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Disposition: inline
In-Reply-To: <4EA036D1.2020004@lauterbach.com>
User-Agent: Mutt/1.5.21 (2010-09-15)
Mailing-List: contact cygwin-help AT cygwin DOT com; run by ezmlm
Precedence: bulk
List-Id: <cygwin.cygwin.com>
List-Unsubscribe: <mailto:cygwin-unsubscribe-archive-cygwin=delorie DOT com AT cygwin DOT com>
List-Subscribe: <mailto:cygwin-subscribe AT cygwin DOT com>
List-Archive: <http://sourceware.org/ml/cygwin/>
List-Post: <mailto:cygwin AT cygwin DOT com>
List-Help: <mailto:cygwin-help AT cygwin DOT com>, <http://sourceware.org/ml/#faqs>
Sender: cygwin-owner AT cygwin DOT com
Mail-Followup-To: cygwin AT cygwin DOT com
Delivered-To: mailing list cygwin AT cygwin DOT com

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
    set to FILE_SHARE_VALID_FLAGS:

      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
  FILE_SHARE_DELETE.

    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>

int
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;
}
EOF
$ 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

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

--
Problem reports:       http://cygwin.com/problems.html
FAQ:                   http://cygwin.com/faq/
Documentation:         http://cygwin.com/docs.html
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple