Subject: Re: open() giving ENOENT when trying to create files with control chars
From: Yitzchak Scott-Thoennes <[email-masked]>
To: Eric Blake <[email-masked]>
Cc: [email-masked]
Date: Thu, 8 Dec 2005 23:43:55 -0800

On Fri, Dec 09, 2005 at 12:31:32AM +0000, Eric Blake wrote:
> From: Yitzchak Scott-Thoennes <[email-masked]>
> > 
> > Moving on to another "non-portable" problem, I want to create a file
> > with a space at the end of the name, but cygwin is stripping spaces.
> > Despite the comment in the code, this does seem to be allowed (though
> > I suspect it may be via NtCreateFile only, since windows commands
> > don't seem to handle filenames with spaces at the end well).  I tried
> > this:
> 
> Windows strips trailing spaces and dots (unless the file name
> consists only of spaces).  You need a managed mount to
> preserve those; otherwise "foo ", "foo.", "foo. . . . ", "foo",
> and a bunch of other spellings all refer to the same file.

I attempted to indicate in the message above that I tried it and
succeeded in using filenames with spaces on the end (and *different*
files named the same except without the spaces).  It seems this is
*not* an across-the-board Windows limitation.

> Unlike in the other case (non-portable characters, which POSIX
> allows an implementation to reject), the stripping of trailing
> '.' from filenames is a violation of POSIX, but since Windows
> is the culprit, cygwin cannot avoid it (except with the overhead
> of managed mounts).

In the case of ., I'm not sure we would want it allowed it even if
Windows made it possible; too backward incompatible with those cases
where a filename is specified with a . to indicate no default
extension be added (e.g. gcc foo.c -o foo.).

--
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/