Mail Archives: cygwin/2005/09/19/15:31:35
Igor Pechtchanski wrote:
> Yes, there are issues to work out here, but they are not very different
> from, say, those arising when two programs try creating a file with the
> same name simultaneously... In fact, the case-insensitivity of both NTFS
> and VFAT plays into our hands here, as you say below: creating a new file
> that differs only in case will always fail, so Cygwin simply has to encode
> the file name if its creation failed.
It's still extra system calls that would slow things down. And what if
you tried to open("readme") when README exists? It would succeed (on
anything but NT with NTFS with Cygwin using the Native API), but on a
managed mount it's supposed to fail.
And what if "README" exists, and you want to create "readme"? Okay, so
you have to encode "readme" as "%52%65%41%44%4d%65". Now you delete
"README", leaving only "%52%65%41%44%4d%65". A program tries to
open("readme") -- this fails when it should succeed. Cygwin would have
to know to sometimes try "readme" and sometimes try "%52%65%41%44%4d%65"
when the program tries to open "readme", how would it know this without
looking at every file in the directory? Repeat for "readme" vs.
"Readme" and every other of billions of permutation of case. I see no
way this wouldn't turn into a nightmare.
Encoding every filename seems like a win-win situation to me. The only
overhead is the string processing aspect of translating "a" into "%41".
There are no added filesystem calls because every filename is turned
into a canonical unique filename. If you let "readme" sometimes be
"readme" and sometimes be "%52%65%41%44%4d%65", all hell breaks loose.
Brian
--
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/
- Raw text -