This is the mail archive of the cygwin-developers 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: Filenames with Win32 special characters (or: Interix filename compatibility)


On Mar 12 11:53, Brian Dessent wrote:
> Corinna Vinschen wrote:
> 
> > Is that really a problem?  I mean, you're creating files with characters
> > which you didn't expect to work on a Windows file system at all before.
> > How is allowing that a regression?  You also can't access files called
> 
> It's a regression in that currently the mangling used is ugly but
> universally readable.  Say for example you are using a managed mount to
> contain linux kernel source code.  Today you can still do e.g.
> "win32-vim $(cygpath -w FOOBAR.c)" and be able to open/edit/close
> FOOBAR.c, it will just see it with some uglified name.  The new managed
> mount essentially means that the files are off limits to any app that's
> not either a Cygwin app or unicode aware, which includes almost all
> mingw tools for example.  (I use win32-vim as an example simply because
> it's common for people to still use native text editors, as I'm
> personally guilty.)
> 
> Not that I think this in any way should hinder adopting the new method,
> I'm just pointing out that there could be no-so-far-out-there scenarios
> that would break.

Yeah, right.  It's a matter of what we want.  Personally I don't give a
**** for non-Cygwin applications accessing the managed mount content.
What about this scheme for special DOS chars in non-managed mounts?  Do
you expect to access these files, which just didn't exist before, using
a native ANSI tool?


Corinna

-- 
Corinna Vinschen                  Please, send mails regarding Cygwin to
Cygwin Project Co-Leader          cygwin AT cygwin DOT com
Red Hat


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