From: Brian Inglis <Brian.Inglis@Shaw.ca>
To: cygwin@cygwin.com
Cc: Gionatan Danti <g.danti@assyoma.it>
Subject: Re: Can not stat file with utf char U+F020
Date: Fri, 14 Apr 2023 23:10:47 -0600 [thread overview]
Message-ID: <60ce2271-99e4-3fc9-5073-7a36ba202c20@Shaw.ca> (raw)
In-Reply-To: <8f4e63968f4cc73093f7ebbb32788286@assyoma.it>
On 2023-04-14 14:17, Gionatan Danti via Cygwin wrote:
> Il 2023-04-14 21:00 Corinna Vinschen ha scritto:
>> There's no (good) solution from inside Cygwin.
> 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."
> 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?
> [1] https://en.wikipedia.org/wiki/Private_Use_Areas#Vendor_use
Now if MS SfM and Cygwin had both registered with U/CSUR, they would not be
fighting over Unicode code points, although it looks like there is a lot of
competition for the code points! ;^>
Would it make more sense to add custom file name character filters into some
utility, such as unix2dos/mac2unix, cygpath, or some other, and add (Cyg)win, or
create such a utility, so those could be added to processes?
--
Take care. Thanks, Brian Inglis Calgary, Alberta, Canada
La perfection est atteinte Perfection is achieved
non pas lorsqu'il n'y a plus rien à ajouter not when there is no more to add
mais lorsqu'il n'y a plus rien à retirer but when there is no more to cut
-- Antoine de Saint-Exupéry
next prev parent reply other threads:[~2023-04-15 5:10 UTC|newest]
Thread overview: 19+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-04-14 17:53 Gionatan Danti
2023-04-14 19:00 ` Corinna Vinschen
2023-04-14 19:54 ` Brian Inglis
2023-04-14 20:20 ` Corinna Vinschen
2023-04-14 20:21 ` Gionatan Danti
2023-04-14 20:25 ` Corinna Vinschen
2023-04-14 21:01 ` Gionatan Danti
2023-04-17 5:36 ` Gionatan Danti
2023-04-17 9:05 ` Corinna Vinschen
2023-04-17 10:58 ` Andrey Repin
2023-04-17 13:46 ` Gionatan Danti
2023-04-18 21:09 ` Gionatan Danti
2023-04-19 1:10 ` L A Walsh
2023-04-19 11:56 ` Gionatan Danti
2023-04-14 20:17 ` Gionatan Danti
2023-04-14 20:40 ` Corinna Vinschen
2023-04-14 20:51 ` Gionatan Danti
2023-04-15 5:10 ` Brian Inglis [this message]
2023-04-17 9:10 ` Corinna Vinschen
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=60ce2271-99e4-3fc9-5073-7a36ba202c20@Shaw.ca \
--to=brian.inglis@shaw.ca \
--cc=cygwin@cygwin.com \
--cc=g.danti@assyoma.it \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).