Re: file name inconsistencies
On Jan 20 21:19, Eric Blake wrote: Second, cygwin does not conform to POSIX when performing pathname resolution. POSIX requires, in http://www.opengroup.org/onlinepubs/009695399/basedefs/xbd_chap04.html#tag_04_11 and in many of the syscalls, that the call fail if any component of the pathname is inaccessible. For example, stat() is required to fail with EACCES if search permission is denied for any component of the path prefix, but this example shows that cygwin is succeeding: $ cd /tmp $ mkdir d d/d1 $ chmod 0 d $ touch d/d1/f # should fail, d is inaccessible $ ls d/d1 # should fail, d is inaccessible f $ However, this may be a bug in the underlying Windows OS. I opened up Windows explorer, then browsed to the location of /tmp. Clicking on d gives C:\cygwin\tmp\d is not accessible. Access is denied. But going to the address bar, and typing in c:\cygwin\tmp\d\d1 browses right to that supposedly inaccessible nested directory! Is it worth fixing cygwin to reject paths to comply with POSIX, when Windows can still access such paths? Or is there something wrong in the ACL manipulation going on with `chmod 0', so that it is not really stripping all access rights? We (the Cygwin developers) discussed this already long ago and came to the conclusion that it's not worth the hassle. Actually it's not a Windows bug, but a feature. NT knows about a user right called Bypass traverse checking, SeChangeNotifyPrivilege, which is given to all users by default. This is the right, which allows a user to access all files with a matching ACL, without checking the parent folders. What you should be able to do (but which I never tested myself) is, to remove this right from your own process, so that this process works automatically under POSIX access rules. The problem is that we can't do this in Cygwin without asking for a lot of trouble. We don't know how people manage their system, resp. how their admins manage their system. I can easily imagine that after doing this automatically in Cygwin, Cygwin applications don't work anymore on 50% of the installations. I'm not sure if I really want that :-) Finally, is there any reason that `df --local' cannot find any local filesystems? It is rather odd to see the coreutils testsuite skip tests because there is no local filesystem that it can find, when I know for a fact that my machine has a local hard-drive at c:\. Debugging helps. See coreutils/lib/mountlist.h #ifndef ME_REMOTE /* A file system is `remote' if its Fs_name contains a `:' or if (it is of type smbfs and its Fs_name starts with `//'). */ # define ME_REMOTE(Fs_name, Fs_type)\ (strchr ((Fs_name), ':') != 0 \ || ((Fs_name)[0] == '/'\ (Fs_name)[1] == '/' \ STREQ (Fs_type, smbfs))) #endif Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Project Co-Leader mailto:cygwin@cygwin.com Red Hat, Inc. -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: file name inconsistencies
On Fri, 21 Jan 2005, Corinna Vinschen wrote: On Jan 20 21:19, Eric Blake wrote: [snip] Finally, is there any reason that `df --local' cannot find any local filesystems? It is rather odd to see the coreutils testsuite skip tests because there is no local filesystem that it can find, when I know for a fact that my machine has a local hard-drive at c:\. Debugging helps. See coreutils/lib/mountlist.h #ifndef ME_REMOTE /* A file system is `remote' if its Fs_name contains a `:' or if (it is of type smbfs and its Fs_name starts with `//'). */ # define ME_REMOTE(Fs_name, Fs_type)\ (strchr ((Fs_name), ':') != 0 \ || ((Fs_name)[0] == '/'\ (Fs_name)[1] == '/' \ STREQ (Fs_type, smbfs))) #endif I recall there was even a patch submitted for this a while ago (for fileutils, though). Igor -- http://cs.nyu.edu/~pechtcha/ |\ _,,,---,,_[EMAIL PROTECTED] ZZZzz /,`.-'`'-. ;-;;,_[EMAIL PROTECTED] |,4- ) )-,_. ,\ ( `'-' Igor Pechtchanski, Ph.D. '---''(_/--' `-'\_) fL a.k.a JaguaR-R-R-r-r-r-.-.-. Meow! The Sun will pass between the Earth and the Moon tonight for a total Lunar eclipse... -- WCBS Radio Newsbrief, Oct 27 2004, 12:01 pm EDT -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
file name inconsistencies
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 First off, I knew that Windows does not allow trailing '.' in filenames (or rather, it strips them). But until today, I did not know that trailing spaces are also stripped. It would be nice if this were documented in the FAQ, maybe as an addition to the DOS special filenames section. Also, I found out when debugging coreutils testsuite failures that in addition to ?/?, ?\?, ???, ?*?, ?:?, ??, ??, ?|? and ?? (the forbidden characters listed in the autoconf portability documentation), that windows does not support '\t', '\n', '\r', '\f', '\l', '\v', '\a', or any other control characters in filenames. $ cd /tmp $ ls $ touch 'f.' $ touch 'f ' $ touch 'f. . . .. . .' $ touch 'f^G' # literal '\a' character, enter using ^v-^g touch: cannot touch `f': No such file or directory $ touch ' ' touch: cannot touch ` ': No such file or directory $ ls f $ And that means there is a bug in managed mount points - filenames ending in space(s) currently get stripped ALL trailing spaces and dots removed: $ cd /managed $ ls $ touch 'f.' $ touch 'f ' $ touch 'f^G' # literal '\a' character, enter using ^v-^g $ touch 'f. . . .. .' $ touch 'g.. ' $ touch ' ' touch: cannot touch ` ': No such file or directory $ ls -Q f f\a f. f. . . .. . g $ Second, cygwin does not conform to POSIX when performing pathname resolution. POSIX requires, in http://www.opengroup.org/onlinepubs/009695399/basedefs/xbd_chap04.html#tag_04_11 and in many of the syscalls, that the call fail if any component of the pathname is inaccessible. For example, stat() is required to fail with EACCES if search permission is denied for any component of the path prefix, but this example shows that cygwin is succeeding: $ cd /tmp $ mkdir d d/d1 $ chmod 0 d $ touch d/d1/f # should fail, d is inaccessible $ ls d/d1 # should fail, d is inaccessible f $ However, this may be a bug in the underlying Windows OS. I opened up Windows explorer, then browsed to the location of /tmp. Clicking on d gives C:\cygwin\tmp\d is not accessible. Access is denied. But going to the address bar, and typing in c:\cygwin\tmp\d\d1 browses right to that supposedly inaccessible nested directory! Is it worth fixing cygwin to reject paths to comply with POSIX, when Windows can still access such paths? Or is there something wrong in the ACL manipulation going on with `chmod 0', so that it is not really stripping all access rights? Finally, is there any reason that `df --local' cannot find any local filesystems? It is rather odd to see the coreutils testsuite skip tests because there is no local filesystem that it can find, when I know for a fact that my machine has a local hard-drive at c:\. - -- Life is short - so eat dessert first! Eric Blake [EMAIL PROTECTED] -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.0 (Cygwin) Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org iD8DBQFB8ILo84KuGfSFAYARAu9vAJ0bGB8DoPbgsPZJhRoaU0uWu6o4/wCfdmbJ z6veOBdhS7UMc9hnfQXiYfc= =mWAO -END PGP SIGNATURE- -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
