Poslední příspěvky1
Windows a jiné systémy / Re:Mac UTF-8 a Samba s vfs_fruit
« Poslední příspěvek od Michal Šmucr kdy Dnes v 00:41:40 »Taky si to ozkouším, až budu mít chvilku.. díky, že jste poslal konkrétní hex kódy těch znaků, co vás zlobí.
Ale bohužel se obávám, že tím co zkoušíte s vfs_fruit se tohle nevyřeší.
fruit:encoding řeší specificky jen chování CIFS klienta na MacOS když vytváří na share nový soubor, který obsahuje znaky, co jdou použít na HFS a APFS, ale nejdou použít na Windows (dvojtečka, lomítka, je větší, menší, pípa..). Ty pak přemapuje do privátního rozsahu Unicode. Tenhle rozsah pak Windows CIFS klienti ignorují, takže se souborem můžou normálně pracovat. Zároveň, když je tam MacOS klient má, tak si je remapuje zpátky.
Takhle se to chová bez jakéhokoliv spec. nastavení v MacOSu.
Když tam přidáte direktivu vfs_fruit:encoding = native, tak můžete změnit to, že to na serveru uloží soubor tak, že tam do jmén na standardní umístění místo neviditelných priv. kódů vrátí znaky, co jdou na UNIXech uložit (tzn. téměř vše mimo dopředného lomítka).
Pokud neuděláte nic, nebo explicitně nastavíte vfs_fruit:encoding = private, tak se to chová tak, jak jsem popisoval předtím.
vfs modul fruit neumí sám o sobě přemapovávat znaky, ale používá na to modul catia, kterému dynamicky předá potřebná přemapování, proto se musí při použití encoding = native stackovat dohromady s fruit.
Jinak ty ostatní volby fruit s tímhle nemají moc co do činění, při připojení z MacOS přidají do SMB protokolu některé Apple extenze, řeší různé způsoby ukládání metadat a resource forků, rekurzivní zamykání atd. Tzn. s největší pravděpodobností to ničemu nevadí, ale vašemu problému to nejspíš nepomůže.
Jediné, co by mohlo teoreticky něco řešit je zmíněný modul catia.
Ten umí i manuální remapování jednotlivých znaků (nejsem si jistý, ale sekvenci dvou znaků po sobě to podle mě nepobere, když se tam zadává mapa).
Ten by se pak nastavil na share, který by byl určený jen pro MacOS klienty a zkusil bych udělat mapu pro kódy samostatných znaků s akcenty (v češtině asi jen čárka, háček, kroužek a přehláska) a každý z nich nahradil nějakým jedinečným kódem pro nepoužívaný ufonský znak, u kterého si vyzkouším, že nedělá ve Finderu problém.
Ta mapa musí funguovat oběma směry, tzn. když MacOS klient soubor zapíše zpět, tak aby se to spolehlivě vrátilo do původního názvu, který se používá na share pro Windows klienty. Proto to například nejde jednoduše nahradit všechny akcenty třeba jednou univerzální pomlčkou (kdyby se ve jméně vyskytlo více různých akcentů, tak by to zpátky uložilo jiné jméno souboru).
Ale to je samozřejmě jen nápad
Ale bohužel se obávám, že tím co zkoušíte s vfs_fruit se tohle nevyřeší.
fruit:encoding řeší specificky jen chování CIFS klienta na MacOS když vytváří na share nový soubor, který obsahuje znaky, co jdou použít na HFS a APFS, ale nejdou použít na Windows (dvojtečka, lomítka, je větší, menší, pípa..). Ty pak přemapuje do privátního rozsahu Unicode. Tenhle rozsah pak Windows CIFS klienti ignorují, takže se souborem můžou normálně pracovat. Zároveň, když je tam MacOS klient má, tak si je remapuje zpátky.
Takhle se to chová bez jakéhokoliv spec. nastavení v MacOSu.
Když tam přidáte direktivu vfs_fruit:encoding = native, tak můžete změnit to, že to na serveru uloží soubor tak, že tam do jmén na standardní umístění místo neviditelných priv. kódů vrátí znaky, co jdou na UNIXech uložit (tzn. téměř vše mimo dopředného lomítka).
Pokud neuděláte nic, nebo explicitně nastavíte vfs_fruit:encoding = private, tak se to chová tak, jak jsem popisoval předtím.
vfs modul fruit neumí sám o sobě přemapovávat znaky, ale používá na to modul catia, kterému dynamicky předá potřebná přemapování, proto se musí při použití encoding = native stackovat dohromady s fruit.
Jinak ty ostatní volby fruit s tímhle nemají moc co do činění, při připojení z MacOS přidají do SMB protokolu některé Apple extenze, řeší různé způsoby ukládání metadat a resource forků, rekurzivní zamykání atd. Tzn. s největší pravděpodobností to ničemu nevadí, ale vašemu problému to nejspíš nepomůže.
Jediné, co by mohlo teoreticky něco řešit je zmíněný modul catia.
Ten umí i manuální remapování jednotlivých znaků (nejsem si jistý, ale sekvenci dvou znaků po sobě to podle mě nepobere, když se tam zadává mapa).
Ten by se pak nastavil na share, který by byl určený jen pro MacOS klienty a zkusil bych udělat mapu pro kódy samostatných znaků s akcenty (v češtině asi jen čárka, háček, kroužek a přehláska) a každý z nich nahradil nějakým jedinečným kódem pro nepoužívaný ufonský znak, u kterého si vyzkouším, že nedělá ve Finderu problém.
Ta mapa musí funguovat oběma směry, tzn. když MacOS klient soubor zapíše zpět, tak aby se to spolehlivě vrátilo do původního názvu, který se používá na share pro Windows klienty. Proto to například nejde jednoduše nahradit všechny akcenty třeba jednou univerzální pomlčkou (kdyby se ve jméně vyskytlo více různých akcentů, tak by to zpátky uložilo jiné jméno souboru).
Ale to je samozřejmě jen nápad
