Mail Archives: cygwin/2009/07/15/16:48:56
On Jul 15 19:42, Eric Blake wrote:
> New thread (gmane gave me grief at finding the old one, and anyways, I'm adding
> a couple new topics to the mix).
>
> $ attrib foo
> M:\foo
> $ attrib +r +s foo
> $ attrib foo
> R M:\foo
> $ rm foo
> rm: remove write-protected regular empty file `foo'? y
> rm: cannot remove `foo': Permission denied
Huh? This looks like a bug in unlink. It's supposed to delete the
R/O flag prior to trying to delete the file. This should look like:
$ rm foo
rm: remove write-protected regular empty file `foo'? y
$
[...time passes...]
Hmm, no, it works fine on FAT. Why does removing the R/O flag not work
on MVFS?
[...more time passes...]
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.
This reminds me of the problem we have with remote HPFS filesystems,
which have to be opened with GENERIC_WRITE rather than with
FILE_WRITE_ATTRIBUTES when trying to write timestamps. See below.
> $ attrib -r foo
> $ rm foo
>
> 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.
The fact that the SYSTEM flag is not supported would be easily worked
around by always creating winsymlinks on MVFS. However, this also
requires to find a fix for the above mysterious unlink problem.
> Another one that's been bothering me: cp -p can't preserve times when copying
> from a remote drive (I'm not sure if it is samba, NFS, or something else) over
> to MVFS, but touch can; also, copying from local to MVFS has no problems
> preserving times:
>
> $ echo > /tmp/bar
> $ cp -p /cygdrive/f/foo . # remote to MVFS
> $ ls -l /cygdrive/f/foo foo
> ----------+ 1 eblake Domain Users 925184 Nov 4 2004 cygdrive/f/foo
> -r--r--r-- 1 eblake Domain Users 925184 Jul 15 13:33 foo
> $ touch --ref cygdrive/f/foo foo
> $ ls -l /cygdrive/f/foo foo
> ----------+ 1 eblake Domain Users 925184 Nov 4 2004 /cygdrive/f/foo
> -r--r--r-- 1 eblake Domain Users 925184 Nov 4 2004 foo
> $ cp -p /tmp/bar bar # local to MVFS
> $ ll /tmp/bar bar
> -rw-r----- 1 eblake Domain Users 1 Jul 15 13:26 /tmp/bar
> -rw-r--r-- 1 eblake Domain Users 1 Jul 15 13:26 bar
> $ touch bar
> $ ll /tmp/bar bar
> -rw-r----- 1 eblake Domain Users 1 Jul 15 13:26 /tmp/bar
> -rw-r--r-- 1 eblake Domain Users 1 Jul 15 13:37 bar
>
> Do you need any straces for any of these actions?
Well, actual debugging and trying to find the problem would be preferred.
It's not fun to debug something only available by proxy.
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.
However, for the delete case I have a hunch that changing syscalls.cc,
line 457 from
access |= FILE_WRITE_ATTRIBUTES;
to
access |= GENERIC_WRITE;
will fix the problem on MVFS. Please try this and report back.
Once we have fixed this one, we can look into the timestamp problem.
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
- Raw text -