This is the mail archive of the
cygwin-developers@cygwin.com
mailing list for the Cygwin project.
RE: Added some interesting functionality to my cygwin sandbox
- From: "Williams, Gerald S (Jerry)" <gsw at agere dot com>
- To: cygwin-developers at cygwin dot com
- Date: Wed, 2 Jul 2003 08:08:47 -0400
- Subject: 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