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
