open() giving ENOENT when trying to create files with control chars
Mon Dec 5 11:23:00 GMT 2005
Corinna Vinschen <corinna-cygwin <at> cygwin.com> 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: http://cygwin.com/ml/#unsubscribe-simple
Problem reports: http://cygwin.com/problems.html
More information about the Cygwin