Mail Archives: cygwin/2005/09/19/16:01:19
On Mon, 19 Sep 2005 15:48:01 -0400 (EDT), Igor Pechtchanski wrote:
>On Mon, 19 Sep 2005, Brian Dessent wrote:
>> 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.
>Which was what I said in the part you snipped.
>> 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?
>Of course, it goes without saying that the encoded form should always work
>(yes, there may be clashes like "readme" created by Windows and
>"%52%45%41%44%4d%45" created by Cygwin, but those are unavoidable). As
>for knowing which file to open, first look for "%52%45%41%44%4d%45", then
>for "readme" (case-sensitively). No other possibilities here...
>> 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.
>Huh? Why would you need to try *all* the permutations?
>> Encoding every filename seems like a win-win situation to me. The only
>> overhead is the string processing aspect of translating "a" into "%41".
>Which may or may not be considerable (and no, I don't have measurements to
>back it up). There is another overhead, and that is of a human trying to
>look at the directory with Windows tools. Yes, encoding is unavoidable,
>but it shouldn't be obnoxious.
>> 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.
>Yes, it doubles the number of calls needed to open the file. So? Nobody
>said managed mounts would have no overhead.
>OTOH, the issue of "readme" and "%52%45%41%44%4d%45" being the same is
>valid, and needs to be handled somehow.
> Igor
Has anyone explored the option of an IFS that would implement the cygwin
managed filesystem semantics, but it would be transparent to all
cygwin apps. From the brief investigation I have done, it appears there would
need to be 2 flavors, 9x/ME & NT/2K/XP, but that would relieve a big burden
from the cygwin1.dll, I would estimate.
>--
> http://cs.nyu.edu/~pechtcha/
> |\ _,,,---,,_ pechtcha AT cs DOT nyu DOT edu
>ZZZzz /,`.-'`' -. ;-;;,_ igor AT watson DOT ibm DOT com
> |,4- ) )-,_. ,\ ( `'-' Igor Pechtchanski, Ph.D.
> '---''(_/--' `-'\_) fL a.k.a JaguaR-R-R-r-r-r-.-.-. Meow!
>If there's any real truth it's that the entire multidimensional infinity
>of the Universe is almost certainly being run by a bunch of maniacs. /DA
>--
>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/
--
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 -