This is the mail archive of the cygwin mailing list for the Cygwin project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

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


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
-- 
				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/


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]