Can not stat file with utf char U+F020
Corinna Vinschen
corinna-cygwin@cygwin.com
Fri Apr 14 20:40:02 GMT 2023
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
More information about the Cygwin
mailing list