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

Bill Hughes
Mon Dec 5 11:23:00 GMT 2005

Corinna Vinschen <corinna-cygwin <at>> writes:

> On Dec  5 10:11, Bill Hughes wrote:
> > Uh, don't forget this is the NTFS API and not the Windows API.
> > If you want to go down this route you may as well add case sensitive file
> > names too...
> That's not quite right.  Case-sensitivity is a flag which can be
> switched on and off at will.  It's a property of the driver, not the
> underlying file system.  The underlying file system is obviously capable
> of storing case-sensitive filenames, the driver just handles characters
> only differing by case as equal in the default Windows case.  The above
> is converting invalid characters to valid characters.  These new
> characters are still valid characters even when you're working in a
> plain ASCII (or ISO-8859) environment, since NTFS stores the filenames
> in UNICODE anyway.
OK, I wasn't aware that you could persuade windows to use the case-sensitive
abilities of NTFS without hacking.
I'm not sure it would be obvious that the FS is capable of case sensitive
operations if we didn't already know that - to me it's equally obvious that FAT
isn't capable of these. Unless I'm wrong again of course.

> I'm not sure until I tried it, of course, but I don't think this will
> result in problems with Windows, just because your standard font can't
> display the characters.
Agreed, not on an NTFS filesystem anyway.
I tend to use FAT at home for dual boot machines so I can access the windows
disks read/write from linux as the ntfs write ability has had warnings attached
for a long time. Come to that I use fat for my XP box so I can use a linux
rescue cd when it goes wrong, hence my concerns about cygwin adding value to
NTFS ops that wouldn't apply to FAT.

Sorry if this is just noise,

Unsubscribe info:
Problem reports:

More information about the Cygwin mailing list