This is the mail archive of the cygwin-talk 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: Handling special characters (\/:*?"<>|) gracefully


Brian Dessent wrote:
> As I understand it, the win32 API preserves case but is not case
> sensitive.  The native API is both, so in theory an application that
> used only native calls could cope with both README and Readme, but no
> win32 app could.  So, from the standpoint of Cygwin this is pretty
> useless as A) it would take significant code rewrites to use
> the native API everywhere (not to mention backcompat hell for 9x/ME)
> and B) it would lead to the situation (which we briefly got a taste
> of somewhere in a past 1.5.x release) where Cygwin was able to create
> files that could not be deleted by Explorer or any other regular
> Windows app.

I don't want to gum up the main list with this discussion...

If you wanted to make such a change in Cygwin, you wouldn't
retarget the native API, rather, you'd retarget replacements
for the 24 (or so) functions in the Win32 API that stop you
from using native naming (these would also handle backward
compatibility). I know I'm just being pedantic here, since
Cygwin already took a different route, but such a thing is
feasible--I looked into it pretty closely at one time.

Yes, it's interesting creating files that Windows utilities
can't touch (e.g., "con"). And if they try to access either
of "hello" and "Hello" they'll only get one (they can still
delete both, one at a time). I'd call these "stupid Windows
tricks" but I'm sure there's some form of redundancy in that
expression.

On the other hand, files named "cyg%4D%49%4E%47" aren't
all that amenable to manipulation via Windows utilities
either, so to some degree it's a matter of perspective.

gsw


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