Corinna Vinschen <corinna-cygwin <at> cygwin.com> writes:
> Eric, can you please change syscalls.cc, line 532 from
>
> NtSetAttributesFile (fh, pc.file_attributes () & ~FILE_ATTRIBUTE_READONLY);
>
> to
>
> {
> status = NtSetAttributesFile (fh, pc.file_attributes () &
~FILE_ATTRIBUTE_READONLY);
> if (!NT_SUCCESS (status))
> system_printf ("Blah: %p", status);
> }
>
> and see what status code is returned? Hmm, it's possible that
> it doesn't print anything because it doesn't even reach this code.
By itself, the Blah is never printed.
> > Just as we suspected, MVFS doesn't support DOS attributes, which also
> > interferes with deletion abilities (I can also use 'chmod a+w' instead
> > of 'attrib -r' to get deletion to work).
>
> This is really weird. The R/O flag *is* supported, the SYSTEM flag
> isn't. I assume the HIDDEN flag isn't either, but that's a minor
> problem.
You are correct, 'attrib +h' has no effect. I also suspect that the R/O flag
is being faked based on write permissions. That is, I can do:
$ attrib foo
M:\foo
$ chmod a-w foo
$ attrib foo
R M:\foo
>
> As I said above, I assume that MVFS has a problem similar to what we
> have for remote HPFS. It's not sufficient to set only the minimal
> set of access flags in calls to NtCreateFile/NtOpenFile in some
> circumstances. I can't tell where the problem is for cp -p since that
> shouldn't call anything different from touch in terms of setting timestamps.
utimensat vs utimens?
>
> However, for the delete case I have a hunch that changing syscalls.cc,
> line 457 from
>
> access |= FILE_WRITE_ATTRIBUTES;
>
> to
>
> access |= GENERIC_WRITE;
Even with this added to the patch, it still doesn't seem to help. But
something weird is certainly going on:
Breakpoint 1, unlink_nt (p...@0x2247f4)
at ../../../../winsup/cygwin/syscalls.cc:445
445 unlink_nt (path_conv &pc)
(gdb) n
452 ACCESS_MASK access = DELETE;
(gdb)
456 if (pc.file_attributes () & FILE_ATTRIBUTE_READONLY)
(gdb)
457 access |= GENERIC_WRITE;
(gdb)
459 ULONG flags = FILE_OPEN_FOR_BACKUP_INTENT;
(gdb)
462 if (pc.is_rep_symlink ())
(gdb)
465 pc.get_object_attr (attr, sec_none_nih);
(gdb)
472 bin_status bin_stat = dont_move;
(gdb)
473 status = NtOpenFile (&fh, access, &attr, &io, FILE_SHARE_DELETE,
flags);
(gdb) p fh
$1 = (HANDLE) 0x2247f4
(gdb) p access
$2 = 1073807360
(gdb) p attr
$3 = {Length = 24, RootDirectory = 0x0, ObjectName = 0x224814, Attributes = 0,
SecurityDescriptor = 0x0, SecurityQualityOfService = 0x0}
(gdb) p io
$4 = {Status = 0, Information = 0}
(gdb) p flags
$5 = 16384
(gdb) s
/home/eblake/coreutils/src/rm: cannot remove `foo': Permission denied
Program exited with code 01.
Basically, the NtOpenFile took over execution (I'm guessing that it triggered a
fault handler, which interfered with single stepping?). My next attempt:
(gdb) b 641
Breakpoint 2 at 0x610e2e3c: file ../../../../winsup/cygwin/syscalls.cc, line
641.
Breakpoint 2, unlink (
ourname=0x6b0038 "/project/fabt/foo")
at ../../../../winsup/cygwin/syscalls.cc:641
641 if (NT_SUCCESS (status))
(gdb) p/x status
$7 = 0xc0000022
(gdb) n
644 __seterrno_from_nt_status (status);
(gdb)
/home/eblake/coreutils/src/rm: cannot remove `foo': Permission denied
Program exited with code 01.
Now, even __seterrno_from_nt_status is running away.
Any ideas on what I should try next?
--
Eric Blake
--
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
