Re: Can not stat file with utf char U+F020

[Corinna Vinschen <corinna-cygwin@cygwin.com>]

On Apr 14 22:17, Gionatan Danti via Cygwin wrote:
> Il 2023-04-14 21:00 Corinna Vinschen ha scritto:
> > There's no (good) solution from inside Cygwin.
> > [snip]
> 
> Yeah, I can only imagine how difficult is to be compatible with posix, win32
> and the likes.
> 
> > Any chance you can just rename the files?
> 
> I renamed the files, in fact.
> 
> However, it seems that users working with (older?) Office for MAC use U+F020
> more frequently than I expected, maybe because of that [1]:
> 
> "Microsoft's defunct Services For Macintosh feature used U+F001 through
> U+F029 as replacements for special characters allowed in HFS but forbidden
> in NTFS, and U+F02A for the Apple logo."

Drat.  This is kind of sick.  At the same time, Interix used the
U+F0xx area as we do.  That's why I chose this area, to be filename
compatible with Interix.

> Any chances to enable a "bypass" for these characters (excluding the one you
> reserved for compatibility as explained detailed in the "Forbidden
> characters in filenames")? Maybe hidden behind a configurable option (even
> disabled by default), so to not interfere with the current behavior?

This is really tricky.  A new mount point flag could be used to override
this behaviour on a per path basis.  One problem is, the unicode ->
multibyte conversion when evaluating a symlink is done before it's clear
where the symlink target is.  Only the string is converted and it might
be a relative path, so the code doesn't know where the target ends up.
And that's probably not all.

Is it really worth to add code to support a long deprecated Windows
service?


Corinna