This is the mail archive of the
mailing list for the Cygwin project.
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
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)
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.
[handle lev2 and lev3]
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
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
int fd1, fd2;
if (mkdir ("lev1", 0700) < 0)
fprintf (stderr, "mkdir: %s\n", strerror (errno));
fd1 = open ("lev1", O_RDONLY);
if (fd1 < 0)
fprintf (stderr, "open: %s\n", strerror (errno));
fd2 = dup (fd1);
if (fd2 < 0)
fprintf (stderr, "dup: %s\n", strerror (errno));
if (close (fd1) < 0)
fprintf (stderr, "close(fd1): %s\n", strerror (errno));
if (rmdir ("lev1") < 0)
fprintf (stderr, "rmdir: %s\n", strerror (errno));
if (close (fd2) < 0)
fprintf (stderr, "close(fd2): %s\n", strerror (errno));
$ gcc -g -o stc stc.c
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
Problem reports: http://cygwin.com/problems.html
Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple