Re: Bug: Setup tool doesn't respect managed mountpoints/filesystems

[Mark Paulus <mark dot paulus at mci dot com>]

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@cs.nyu.edu
>ZZZzz /,`.-'`'    -.  ;-;;,_		igor@watson.ibm.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/