Greetings, Lester Caine. In reply to Your message dated Saturday, March 21, 2020, 22:37:32, > On 21/03/2020 14:40, Andrey Repin wrote: >> Greetings, Lester Caine. >> In reply to Your message dated Saturday, March 21, 2020, 15:28:41, >> >>> On 21/03/2020 09:25, Christoph M. Becker wrote: >>>> On 21.03.2020 at 02:37, Andrey Repin wrote: >>>> >>>>> Greetings, Lester Caine. >>>>> >>>>> In reply to Your message dated Wednesday, March 18, 2020, 1:03:49, >>>>> >>>>>> On 17/03/2020 19:11, Sam Hobbs wrote: >>>>>> >>>>>>> You still did not answer the question of what OS. The answer for Windows >>>>>>> is not simple. So before doing exotic testing, you really should look at >>>>>>> the documentation for the relevant OS. >>>>>> >>>>>> He said he is on MacOS and the other answers align up with that. The >>>>>> problem is that while Windows is reliably case insensitive and crap on >>>>>> unicode file names, >>>>> >>>>> That's not really true. Windows can be configured for anything you wish, and >>>>> UNICODE names were a problem of PHP, which was solved not-very-recently in V7. >>>> >>>> More precisely, as of PHP 7.1.0: >>>> <https://www.php.net/manual/en/migration71.windows-support.php#migration71.windows-support.long-and-utf8-path>. >> >>> But is far as I am aware windows is STILL using 16 bit per character >> >> It uses UTF-16 for internal representation. Which is far from "16 bit per character". >> >>> wide string format for file names along with somewhat unreliable case >>> conversions on the basic ASCII character subset? >> >> The strength of your desire to attack the OS you dislike is very clear. >> However, I suggest you learn first, attack later. If there's still something >> to attack. > Has windows now migrated to all actions being 'multibyte'? I will admit > it's been some time since I had to look at the code level details, when > wcstring was single 16 bit character string just using the first code > page. I HAVE had problems with copying files using higher code page > characters to windows machines so simply fixed the file name back the > the first code page. I've had opposite experience copying half a terabyte of information from Windows server to Samba share back in 2011. Now what? > The one thing that did pop up is that recent builds of W10 does seem to > have a working UTF8 code page? But I've not been able to find that > reference again :( >> https://stackoverflow.com/a/52203901/1449366 >> >>> While we can use UTF8 characters in Linux file names they do not map through >>> to the windows file name? >> >> They do. It is guaranteed by the UNICODE standard. >> Exceptions to this rule are not in character mapping, but in differences of >> underlying OS/filesystem. >> >> (F.e. you can't reliable represent a dot at the end of a file in Windows, >> while in Linux it is perfectly normal.) >> >>> This is nothing to do with PHP ... >> >> That much is true. > And even today simply copying a file from one OS to another is not a > reliable operation ... Copying a file from one filesystem to another is not a reliable operation. Has nothing to do with OS per se. -- Sincerely Yours, Andrey Repin <anrdaemon@xxxxxxxxxxx>
