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 20:07, Corinna Vinschen wrote:
> 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?

Btw., this access problem potentially also happens to you in Cygwin.
Given you run a shell in codepage:ansi or codepage:oem mode, and in
another codepage:utf8 session you created a file with characters not
available in your ANSI or OEM codepage.  If you try to access this file
in the ansi or oem session, you'll get a ENOENT error.  There's nothing
you can do about that, as soon as you use 8-bit codepages.  That's one
of the reasons to use wide char file access functions.  It's not all
about long path names, it's also about being able to access utf chars,
even if that might still be buggy right now.


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]