This is the mail archive of the cygwin mailing list for the Cygwin project.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: open() giving ENOENT when trying to create files with control chars

On Mon, Dec 12, 2005 at 10:49:52AM +0100, Corinna Vinschen wrote:
>On Dec  8 23:50, Brian Dessent wrote:
>> Yitzchak Scott-Thoennes wrote:
>> > > 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.
>> This is probably a difference in the win32 API versus the native API.
>Correct.  In the native API you can create practically every filename
>which doesn't use invalid characters.  But these filenames are not
>compatible with Win32 functions.  Since the bulk of Cygwin is still
>using the Win32 API, we can't afford to create Win32 incompatible

Even if the bulk of cygwin wasn't using the win32 api, we've already seen
what happens when we create files which can't be manipulated with standard
windows programs.

Maybe at some point we'll have a "semi-managed" mount (because, as you all
know managed mounts are terrifically bad because it's possible that they
will run into the path length limitation more quickly than regular mounts*)
but I don't think we should ever go down the path of blithely creating files
with special characters by default.


* The horror.  The.  Horror.

Unsubscribe info:
Problem reports:

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]