This is the mail archive of the cygwin-developers@cygwin.com 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: Added some interesting functionality to my cygwin sandbox


I wrote:
> >I noticed that aux and Aux differ only by case.

Christopher Faylor wrote:
> This was just an example that differences by case are allowed.

Interesting. When I tried this, I ran into a few problems. Did
you consider:

 - Aliasing: Somehow you have to choose which names to encode.
   Let's say you encode capital letters. But another program
   could create the file Foo.txt. I suppose you could tolower()
   all the chars and treat this as foo.txt, but I was never all
   that happy about that solution, especially once I found out
   that NTFS really DOES support having both Foo.txt and foo.txt
   in the same directory. Granted, by limiting it to a certain
   type of mount, you've constrained the issue and can say "don't
   create files here from outside of Cygwin" if it comes to that.

   I'm assuming you already figured out that there's potentially
   a worse aliasing problem if you decode %66oo.txt (or whatever
   decodes as "foo.txt") in the same directory as foo.txt, since
   you would have two files by the same name. You'd really like
   to select a set of characters that aren't "legal" and decode
   only them. Unfortunately, you have to deal with special-case
   names like "prn" and "aux" as well (not insurmountable, just
   a minor PITA). There's also the question about how to handle
   unrecognized escapes and escaped-escapes (e.g., do "%oo.txt"
   and "%25oo.txt" both decode as "%oo.txt"?). I suppose you can
   apply the "if it hurts, don't do it" answer here as well, but
   there will be a class of file names that Cygwin would not be
   able to access even though they could physically exist on the
   disk. I know that's currently true anyway if you go straight
   to NTFS, but this would apply even to files created at a DOS
   prompt. How do you handle a case where cygpath -u cannot give
   a legal answer?

 - Buffer sizes: ANSI Win32 calls limit path lengths to MAX_PATH
   characters. Potentially nearly tripling the length of paths
   brings you up against that limit far more often.

gsw


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