Mailing-List: contact cygwin-help AT cygwin DOT com; run by ezmlm
Sender: cygwin-owner AT cygwin DOT com
Mail-Followup-To: cygwin AT cygwin DOT com
Message-ID: <41F082E9.6060702@byu.net>
Date: Thu, 20 Jan 2005 21:19:53 -0700
From: Eric Blake <ebb9 AT byu DOT net>
User-Agent: Mozilla Thunderbird 1.0 (Windows/20041206)
MIME-Version: 1.0
To: cygwin AT cygwin DOT com
Subject: file name inconsistencies
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit

-----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             ebb9 AT byu DOT net
-----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/