X-Recipient: archive-cygwin AT delorie DOT com DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org 04899385783F DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cygwin.com; s=default; t=1681504819; bh=6/+DFO6KOoz5CxvY+0Yv+oR1PluaDICL7DJXSVgOeTk=; h=Date:To:Subject:References:In-Reply-To:List-Id:List-Unsubscribe: List-Archive:List-Post:List-Help:List-Subscribe:From:Reply-To:Cc: From; b=gXbm4BJINVT01hxMTlSIpjQxpi+NtsZma35bfrj489cV+OjCMW5kMLE/o/mU2i+nz c+39adHUIz05aO6nimPRhKzWYTMEPx3MAYbn+D0U30pa996WiyJ0qJ+1pCIymDfDrF dWFsQ4mmfzkRq+f8UN25oI5b5Kc35CMpbPUBL/ps= X-Original-To: cygwin AT cygwin DOT com Delivered-To: cygwin AT cygwin DOT com DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org 5A5483858C5E Date: Fri, 14 Apr 2023 22:40:02 +0200 To: Gionatan Danti , Brian Inglis , cygwin AT cygwin DOT com Subject: Re: Can not stat file with utf char U+F020 Message-ID: Mail-Followup-To: Gionatan Danti , Brian Inglis , cygwin AT cygwin DOT com References: <992b3c28d7f1cfc17f7c9bb47b53f770 AT assyoma DOT it> <8f4e63968f4cc73093f7ebbb32788286 AT assyoma DOT it> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: <8f4e63968f4cc73093f7ebbb32788286@assyoma.it> X-BeenThere: cygwin AT cygwin DOT com X-Mailman-Version: 2.1.29 Precedence: list List-Id: General Cygwin discussions and problem reports List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , From: Corinna Vinschen via Cygwin Reply-To: cygwin AT cygwin DOT com Cc: Corinna Vinschen Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Errors-To: cygwin-bounces+archive-cygwin=delorie DOT com AT cygwin DOT com Sender: "Cygwin" 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 -- Problem reports: https://cygwin.com/problems.html FAQ: https://cygwin.com/faq/ Documentation: https://cygwin.com/docs.html Unsubscribe info: https://cygwin.com/ml/#unsubscribe-simple