Added some interesting functionality to my cygwin sandbox

[Christopher Faylor]

On Wed, Jul 02, 2003 at 08:08:47AM -0400, Williams, Gerald S (Jerry) wrote:
>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?

The point of the change is that you are creating files that are intended
to be manipulated by cygwin.  If someone wants to create pathological
cases, using windows programs or functions, to confuse cygwin, then
there will be problems.  Cygwin isn't going to create a 'foo' and a
'%66oo" file.  If you go out of your way to create such a file, then
prepare to be confused.

I'm more concerned about getting the a:foo stuff right than I am about
worrying about people creating files with percent signs.

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

Yes, of course.  There are ways to work around that, at least on NT,
but they would be intrusive.

cgf