From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <corinna@sourceware.org>
Received: by sourceware.org (Postfix, from userid 2155)
	id 5A5483858C5E; Fri, 14 Apr 2023 20:40:04 +0000 (GMT)
DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org 5A5483858C5E
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cygwin.com;
	s=default; t=1681504804;
	bh=S498oiRGaMOLr9LFWzGyzj+AaJvlR23n3u/gQqFAirQ=;
	h=Date:From:To:Subject:Reply-To:References:In-Reply-To:From;
	b=uhFOfkw4h1I7rRa20At0b8/AMMfeeQBAm6kwM76GQunXNEe0lxAW/yMyF9+Z2nqKK
	 l3XPiY5iOiV3ZS/R4Gcj+Gt7XEkI4H21eZUniTlJti3UpFQoR816L4PBvcfiGhA/+z
	 KdlUVFCXaYJKo0MU0hd1dIIbk7QBldnyt3YI5xbY=
Received: by calimero.vinschen.de (Postfix, from userid 500)
	id 8EFD9A81B29; Fri, 14 Apr 2023 22:40:02 +0200 (CEST)
Date: Fri, 14 Apr 2023 22:40:02 +0200
From: Corinna Vinschen <corinna-cygwin@cygwin.com>
To: Gionatan Danti <g.danti@assyoma.it>,
	Brian Inglis <Brian.Inglis@shaw.ca>, cygwin@cygwin.com
Subject: Re: Can not stat file with utf char U+F020
Message-ID: <ZDm6IurD9ykLOoSv@calimero.vinschen.de>
Reply-To: cygwin@cygwin.com
Mail-Followup-To: Gionatan Danti <g.danti@assyoma.it>,
	Brian Inglis <Brian.Inglis@shaw.ca>, cygwin@cygwin.com
References: <992b3c28d7f1cfc17f7c9bb47b53f770@assyoma.it>
 <ZDmiyYS+m0x4QZmh@calimero.vinschen.de>
 <8f4e63968f4cc73093f7ebbb32788286@assyoma.it>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Disposition: inline
In-Reply-To: <8f4e63968f4cc73093f7ebbb32788286@assyoma.it>
List-Id: <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