On Jul 15 22:03, Eric Blake wrote:
> Corinna Vinschen <corinna-cygwin <at> cygwin.com> writes:
> > 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
MVFS reports to have no ACLs so chmod behaves like on FAT. It just
sets or resets the DOS R/O attribute. From our client perspective,
it doesn't matter how it's implemented.
> > 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?
Ultimately the work is done in fhandler_base::utimens_fs() in both
cases.
> > 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:
> [...]
> 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:
Hmm.
> (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
STATUS_ACCESS_DENIED. But why?
> (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?
Not exactly. If I had MVFS here, I'd try various changes to the
arguments to NtOpenFile which make sort of sense.
For instance, maybe it chokes on the sharing flags. I'd try with
FILE_SHARE_VALID_FLAGS instead of just FILE_SHARE_DELETE.
Btw., it's very helpful to observe what happens exactly using
sysinternal's procmon.
How do I get MVFS on my system for testing?
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
