DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org A57B53858D28
Message-ID: <984103a4-ab2d-4337-9964-cc1e3208155d@SystematicSW.ab.ca>
Date: Thu, 19 Sep 2024 08:45:44 -0600
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: readdir() returns inaccessible name if file was created with
 invalid UTF-8
Content-Language: en-CA
To: cygwin@cygwin.com
References: <96f2253b-791b-b8a0-97dd-8d257eefb9b1@t-online.de>
 <bc8bd61c-818e-424f-bb42-52f4fecd4849@towo.net>
 <b6ab074b-919e-4514-8276-72a30c36ab58@towo.net>
 <de4767e2-85b7-ead2-df9a-64e1f24f4e8f@t-online.de>
 <6451a249-adcd-9c56-b76e-1b00886cea80@t-online.de>
 <CAN0SSYx+g4JE6AA6krNAzG6QXrve52TBv0d3VM0SODV-tzZQSQ@mail.gmail.com>
 <66051d82-e2c3-684f-d13f-d1301170b0d4@t-online.de>
Organization: Systematic Software
In-Reply-To: <66051d82-e2c3-684f-d13f-d1301170b0d4@t-online.de>
Precedence: list
From: Brian Inglis via Cygwin <cygwin@cygwin.com>
Reply-To: cygwin@cygwin.com
Cc: Brian Inglis <Brian.Inglis@SystematicSW.ab.ca>
Content-Type: text/plain; charset="utf-8"; Format="flowed"
Errors-To: cygwin-bounces~archive-cygwin=delorie.com@cygwin.com
Sender: "Cygwin" <cygwin-bounces~archive-cygwin=delorie.com@cygwin.com>
Content-Transfer-Encoding: 8bit

On 2024-09-19 07:27, Christian Franke via Cygwin wrote:
> Mark Liam Brown via Cygwin wrote:
>> On Mon, Sep 16, 2024 at 11:51 AM Christian Franke via Cygwin
>> <cygwin@cygwin.com> wrote:
>>> Christian Franke via Cygwin wrote:
>>>> Thomas Wolff via Cygwin wrote:
>>>>> Am 15.09.2024 um 20:15 schrieb Thomas Wolff via Cygwin:
>>>>>> Am 15.09.2024 um 19:47 schrieb Christian Franke via Cygwin:
>>>>>>> If a file name contains an invalid (truncated) UTF-8 sequence, open()
>>>>>>> does not refuse to create the file. Later readdir() returns a
>>>>>>> different name which could not be used to access the file.
>>>>>>>
>>>>>>> Testcase with U+1F321 (Thermometer):
>>>>>>>
>>>>>>> $ uname -r
>>>>>>> 3.5.4-1.x86_64
>>>>>>>
>>>>>>> $ printf $'\U0001F321' | od -A none -t x1
>>>>>>>   f0 9f 8c a1
>>>>>>>
>>>>>>> $ touch 'file1-'$'\xf0\x9f\x8c\xa1''.ext'
>>>>>>>
>>>>>>> $ touch 'file2-'$'\xf0\x9f\x8c''.ext'
>>>>>>>
>>>>>>> $ touch 'file3-'$'\xf0\x9f\x8c'
>>>>>>>
>>>>>>> $ ls -1
>>>>>>> ls: cannot access 'file2-.?ext': No such file or directory
>>>>>>> ls: cannot access 'file3-': No such file or directory
>>>>>>> 'file1-'$'\360\237\214\241''.ext'
>>>>>>> file2-.?ext
>>>>>>> file3-
>>>>>> I don't reproduce this.
>>>> Yes, sorry, the above 'ls' was actually aliased to 'ls --color=auto'
>>>> which needs to call stat(). Plain 'ls' does not, so the errors do not
>>>> occur then.
>>>>
>>>>
>>>>>> While the file name gets mangled, all resulting file names are valid
>>>>>> and
>>>>>> listed:
>>>>>> In file2 the sequence is turned into U+17B3 but exchanged with the dot.
>>>>>> In file3 the same sequence is just dropped.
>>>>>> $ ls -1|cat
>>>>>> file1-🌡.ext
>>>>>> file2-.ឳext
>>>>>> file3-
>>>>>>
>>>>>> However, ls file2* fails, as does ls *.
>>>>> On the other hand, ls file3- fails too, so some mapping error occurs
>>>>> internally.
>>>>> Also, the files cannot be deleted from cygwin (need to use cmd).
>>>> 'rm' using the original names works for file2-..., but not for file3-...
>>>>
>>>> $ rm -v 'file2-'$'\xf0\x9f\x8c''.ext'
>>>> removed 'file2-'$'\360\237\214''.ext'
>>>>
>>>> $ rm -v 'file3-'$'\xf0\x9f\x8c'
>>>> rm: cannot remove 'file3-'$'\360\237\214': No such file or directory
>>>>
>>> Further tests suggest that the problem only occurs with:
>>> - incomplete 4 byte UTF-8 sequences (Unicode above 16 bit)
>>> - complete but invalid 3 byte UTF-8 sequences which encode the UTF-16
>>> 'high surrogate' range (0xD800..0xDBFF).
>> Makes perfect sense, the Windows kernel uses UTF16 internally.
> 
> 
> Yes, but Cygwin does not provide consistent forward/reverse UTF-8 <-> UTF-16 
> mappings. This makes no sense:
> 
> $ touch 'file-'$'\xed\xa0\x80''.ext'  # creates L"file-\xD800.ext" on NTFS
> 
> $ strace ls -F
> ...
> ... fhandler_disk_file::readdir: 0 = readdir(...) (L"file-\xD800.ext" > 
> "file-\xE2\x9E\xB3.ext")
> ...
>   ... stat_worker: -1 = (\??\C:\cygwin64\tmp\file-?.ext,...)
> ...
> ls: cannot access 'file-?.ext': No such file or directory
> file-?.ext
> 
> $ rm -v 'file-'$'\xed\xa0\x80''.ext'
> removed 'file-'$'\355\240\200''.ext'
> 
> The UTF-8 sequence returned by readdir() decodes to U+27B3 (White-Feathered 
> Rightwards Arrow).
> 
> 
> This could be fixed by handling UTF-8 of the surrogate range similar to other 
> invalid sequences: Map each invalid byte to unicode range U+FF80 to U+FFFF. This 
> works as expected if the above UTF-8 sequence is truncated:
> 
> $ touch 'file-'$'\xed\xa0''.ext' # creates L"file-\xF0ED\xF0A0.ext" on NTFS
> 
> $ ls -F
> 'file-'$'\355\240''.ext'

Surrogates halves are invalid for UTF-8 encoding; they should be first be 
encoded as a valid UTF-16 code point.
The encoder should just fail if it encounters any invalid sequence!
Handling surrogates or other invalid values as anything other than invalid turns 
the encoding into what has been called WTF-8 where W may be for Windows! ;^>

-- 
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


-- 
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