"QDir::Separator considered harmful" keci

20.12.2015 23:08 | Přečteno: 1877× | Jiné

Já už jsem dlouho nic nenapsal. A protože se nechcu registrovat na nějakém pochybném webu, tak si tu postěžuju k jednomu zápisku, co jsem našel: QDir::Separator considered harmful. Kdokoliv, ať už trolltech, nokia či digia, nebo kdo to dneska "vlastní" Qt, nebo autor zápisku, vnucují používání '/' jako oddělovače adresářů na Windows, tak jsou hlupani.

Proč? Protože ačkoliv třeba vytvoření souboru s takovým znakem neprojde, pokud použijete zastaralé ANSI api či pochybnou neúplnou cestu ("C:\bla\bla/bla") tak to projde ... protože toto API je "chytré" (čti hloupé) a nahradí vám '/' znakem '\', než to pošle k filesystému. Naštěstí je tu jedno chytré, kterému je to ukradené ... použít unicode verzi (třeba CreateFileW) a skutečnou absolutní cestu ("\\?\C:\bla\bla/bla"), tak se cesta pošle rovnou k filesystému a nebude se jednat o "C:\bla\bla\" + "bla", ale o "C:\bla\" + "bla/bla". Jenže Qt takovým cestičkám nerozumí, je hloupé a limituje vás 260 znaky v cestě kvůli používání zastaralého API. S použitím správného API si můžete pojmenovat cokoliv téměř jakkoliv (v podstatě jako v linuxu, kde kromě oddělovače a nulového byte může být v názvu cokoliv, ve windows je to akorát místo lomítka obrácené lomítko).

No a z toho plyne, že byste rozhodně i nadále měli používat QDir::separator() a dávat si bacha na používání správných lomítek ve Windows. Ale mě jsou windows špehovátka stejně ukradený. Jenom je cílem tohoto zápisku upozornit na bludy šířené uživateli Qt.        

Komentáře

[Jardík]

Né, práci ještě nemám.

[Agent]

Já nevěřím (ani v boha, ani v to, že nemáš práci).

[Odin1918]

A jeste se s tim chlubis! Tak si ji najdi a to co nejrychleji.

[M_train]

A proč by měl? Socialistické praktiky s povinnou zaměstnaností a razítkem v OP bych od tebe nečekal

[Odin1918]

Nejsem pro povinne zamestnavani. Ale pokud muz ve svych skoro 30 letech zije u rodicu a nechava se od nich zivit, coz jim dava zabrat, mel by se okamzite zacit starat sam o sebe. Jeho rodice po nem dokonce chteji, aby si nasel praci, a pravidelne se jej na to dotazuji.

[Aaaautista]

A to nevies ani zadky utierat za peniaze ?

[Bystroushaak]

Né, práci ještě nemám.

Za předpokladu, že bych stvořil technoklášter, kde by lidi mohli meditovat nad algoritmy a programovat od rána do večera, aniž by byli rušeni problémy běžných smrtelníků; šel by jsi k nám šířit programátorskou moudrost, studovat učení, které těší strojového boha a pást beránky?

Náš administrátor shledal tento komentář závadným.

bezobsažný osobní útok

Zobrazit komentář

[Rajce]

S tím se dá v pohodě žít, to mě na Qt trápí asi nejméně

[skunkOS]

A kde je přesně problém? Já používám úplně všude, kde má být oddělovač složek v cestě striktně QDir::separator() a nikdy jsem neměl problém.

Podle mě je prasárna spoléhat na nějakou konverzi lomítek od Qtčka. Je daleko lepší, čistší prostě použít ten wrapper, kterej vrací správná lomítka.

[kralyk z abclinuxu]

Naštěstí je tu jedno chytré, kterému je to ukradené ... použít unicode verzi (třeba CreateFileW) a skutečnou absolutní cestu ("\\?\C:\bla\bla/bla"), tak se cesta pošle rovnou k filesystému a nebude se jednat o "C:\bla\bla\" + "bla", ale o "C:\bla\" + "bla/bla".

Skutečně? Zkoušel jsi to? Já tomu nevěřim. V dokumentaci ke CreateFile se píše:

lpFileName [in]

The name of the file or device to be created or opened. You may use either forward slashes (/) or backslashes (\) in this name.

Imho žádným rozumným způsobem nevytvoříš '/' ve filename ve windows, a i kdybys to nějak nahackoval, běžné windows aplikace vč. exploreru s tím nepočítají, je to zakázany znak, tudíž je zcela na místě v Qt nepoužívat QDir::Separator.

[Jardík]

Však i Microsoftí dokumentace je na některých místech špatná, neaktualizovaná či neúplná. Ano, ve Windows na NTFS filesystému opravdu vytvoříte soubor se znakem '/' v názvu souboru (ale né v průzkumníkovi). Zkuste si to. Dokonce to umí i case-sensitive názvy, použijete-li FILE_FLAG_POSIX_SEMANTIC a zapnete podporu flagu v registru. No a pak se špatně napsané programy, co s tím nepočítají, rozbíjejí, protože nevědí, že soubor "Nazdar jardíku" není "Nazdar Jardíku". tady si můžete o dlouhých názvech počíst. V sekci Naming Conventions, např. stojí

Naming Conventions The following fundamental rules enable applications to create and process valid names for files and directories, regardless of the file system:

• Use any character in the current code page for a name, including Unicode characters and characters in the extended character set (128–255), except for the following reserved characters:
  • / (forward slash)

Z toho mi vyplívá, že to nemáte používat, pokud chcete kompatibility se všemi filesystémy (né jen NTFS). Nezní to tedy jako zákaz, ale doporučení.

Dále

The Windows API has many functions that also have Unicode versions to permit an extended-length path for a maximum total path length of 32,767 characters. This type of path is composed of components separated by backslashes, each up to the value returned in the lpMaximumComponentLength parameter of the GetVolumeInformation function (this value is commonly 255 characters). To specify an extended-length path, use the "\\?\" prefix. For example, "\\?\D:\very long path".

A dále

There is no need to perform any Unicode normalization on path and file name strings for use by the Windows file I/O API functions because the file system treats path and file names as an opaque sequence of WCHARs. Any normalization that your application requires should be performed with this in mind, external of any calls to related Windows file I/O API functions.

A dále poznámka, že shell (průzkumník) je hodně hloupej a na takových cestách se může rozbít.

The shell and the file system have different requirements. It is possible to create a path with the Windows API that the shell user interface is not able to interpret properly.

A nejedná se jen o shell, ale o spoustu (většinu) programů. Všetně programů od MS. To ale neznamená, že budu, jako ten kdo napsal zápisek, vnucovat špatné chování, aby se i jeho program rozbil.

[Jardík]

BTW ntfs3g/fuse jednoho času dovolovat vytvořit na NTFS oddíle (používal POSIX namespace) soubory se zpětným lomítkem (tj. oddělovač cest ve windows) v názvu souboru. Nevím, jestli to ještě dovoluje, nebo ne, ale windows programům se to moc nelíbilo.

[Jardík]

plynout, jejda

[kralyk z abclinuxu]

A nejedná se jen o shell, ale o spoustu (většinu) programů. Všetně programů od MS. To ale neznamená, že budu, jako ten kdo napsal zápisek, vnucovat špatné chování, aby se i jeho program rozbil.

Nechápu, kdes došel k tomu, že to je špatné chování.

Jestli potřebuješ Qt k napsání low-level filesystem utilit, tak použiješ specializované funkce, to je jasné. Běžné Qt I/O API je high-level abstrakce, u které je naopak dobře, že se chová stejně jako Win shell.

Přijde mi to jako snaha být papežtější než papež.

[dumblob]

V reálu je s long paths na Windows jeden zásadní problém - FAT filesystémy (FAT32, exFAT a další nové reinkarnace) jsou dnes nejpoužívanějším (a často jediným podporovaným) filesystémem na přenosných zařízeních (včetne obrovských externích disků, různých karet do kamer a fotoaparátů atd.) a tyto FAT filesystémy NEpodporují long paths (\\?\) a žádné změny se v tomto ohledu neplánují.

Tedy kdo používá long paths hodně riskuje. Ano, ve Windows světě je tohle obrovský problém již od nepaměti a žádné řešení se stále nerýsuje (viz. např. diskuze https://github.com/daokoder/dao-modules/issues/67).

[Agent]

Vážně by mě zajímalo, proč se na těchto zařízeních nepoužívá třeba UDF.

[dumblob]

Ju, tato otázka mě před cca 4 lety napadnula též, ale nyní bych si troufnul již odpovědět uvedením některých možných důvodů:

• neexistuje reálná out-of-the-box podpora ve většině běžných operačních systémech (mj. i já narazil na tento problém - kdysi jsem pálil nějaká CD s novým UDF a na Windows XP a Windows Vista jsem je nepřečetl ani po instalaci speciálních ovladačů)
• ani nejnovější standard UDF nepodporuje větší diskové oddíly než 2TB, což je dnes opravdu málo např. pro externí úložiště
• žádný velký subjekt se o tento formát nezajímá (standardizační organizace dokonce, zdá se, usnula na vavřínech)
• nakonec to nejhorší - ani nejnovější standard UDF nepodporuje názvy souborů delší než 255 bajtů (pro porovnání: Windows mají limit 260 znaků, nikoliv bajtů) i přesto, že je UDF technicky připravené i na delší názvy

[Sten]

Windows od Vista podporují UDF plně, i když se snaží tvářit, že ho neumí (např. naformátovat jde jen z cmd.exe). Linux, BSD a MacOS X podporují UDF plně také. Limit je 2³² × velikost bloku, velikost bloku může být až 4 KiB, pak to zvládne 16 TB.

[kralyk z abclinuxu]

Nicméně v praxi jsem narážel na problematické situace, že např. soubory vytvořené v Linuxu braly widle jako read-only a odmítaly je mazat.

[Sten]

To se stává (nebo alespoň stávalo, novější Windows než Vista jsem nezkoušel), pokud médium plně nevymažete, Windows se z toho nějak pomatou a mají problémy s tím diskem pracovat. IIRC bylo spolehlivé řešení naformátovat to ve Windows, pak to fungovalo všude.

[kralyk z abclinuxu]

Á, máš pravdu. Teď koukám do skriptu, který už pár let používám, že tam vymazání mám. Tak už aspoň vím proč

Skript:

#!/bin/sh


function usage()
{
  echo "Usage: $0 <label> <device>"
  exit 1
}

dev="$2"
label="$1"

[ $# -eq 2 ] || usage
[ -b "$dev" ] || usage

dd if=/dev/zero of="$dev" bs=1M count=1
mkudffs --media-type=hd --blocksize=512 --utf8 --lvid="$label" --vid="$label" --fsid="$label"  "$dev"

[dumblob]

Zajímavé postřehy - je to již pěkná řádka let (minimálně 8), ale skutučně jsem ani na Win XP ani Win Vista nemohl ani jedno CD vypálené s UDF 2.50 či 2.60 přečíst (ale obraz ISO šel z vypálených CD udělat, takže čitelná byla).

Je možné, že podpora byla poté rozšířena/opravena a dnes je situace lepší (dle tabulky na Wikipedii by Win Vista a novější měly podporovat bezproblémově UDF 2.60), ale stále zde máme minimálně to neměnné omezení délky cesty/názvu_souboru.

[kotyz]

Já to používal už kdysi dávno ještě na win 98 nebo 2000 s InCD, nejdřív na CD-RW, potom na DVD-RAM. Akorát mi pak ty disky nešly pod linuxem ani přečíst, protože to bylo naformátovaný na UDF 2.50 a to mi nevzal. Když sem je přeformátoval na UDF 1.50 tak už mi to vzal. Zápis myslim nešel, ale to už si moc nepamatuju, je to cca 10 let. Pak sem se na to vykašlal, protože to fungovalo jen někde a někdy a na linuxu se mi to nepodařilo rozchodit na 100%. Ještě furt mi ty DVD-RAM leží někde ve skříni a asi na nich budou i nějaký data, ale možná už to nepude přečíst. Jestli je najdu tak zkusim jestli ta tabulka na wiki nekecá a linux to od jádra 2.6.26 podporuje až do UDF 2.50 (ale zápis je jen do UDF 2.01, takže ten mi asi nepůjde, ale už nevim jaká verze tam je, zkoušel sem jich několik).

[kotyz]

Tak sem je našel. Na jednom sou fotky a na druhym nic. Podle popisku co sem si tam tenkrát udělal by měli bejt formátovaný jako UDF 2.0. Funguje čtení i zápis. Ale ten zápis trvá strašně mooooc dlouho. I proto sem se na to možná vykašlal...

Ještě bych moh zkusit jak to pude přečíst/zapsat/smazat pod sedmičkama...

[vlastikroot]

Fuj widle!

Pismenka jednotek jsou ten nejhorsi hell na svete. A ty spatny lomitka tomu jeste pridavaj.

[Jardík]

Souhlasím s fůj windle. Teoreticky ale adresářová struktura ve windows začíná "\\". Pak je nějaký device namespace "\\.\XXXXX", pak filesystem namespace, či jak tomu nadávaj "\\?\X:\YYY\ZZZ", UNC "\\?\UNC", a kdovícoještě. Pokud pak různým API nepředáváte takovou úplnou cestu, tak použijou file namespace s různými překlady 'ošklivých' názvů (COM0 apod, mění lomítka atd).

[Kvakor]

... a pokud se v tom někdo chce porochňat, tady je popis namespaces přímo od Microsoftu. Když to srovnám s Linuxem (či ostatními unixy), kde se na všechno (lokální) používá jen jeden namespace a až teprve síťové zdroje (např. při mountování síťových FS) potřebují specifičtější syntaxi (přitom stále je to jen nadmnožina lokálního namespace, tedy s vyjímkou těch, co používají unifikované URL (mimo těch přirozeně pracujících s HTTP třeba SVN)), tak toto je černá magie, navíc s velmi omezeným využítím, protože základní nástroje (tj. ty, které používají BFU) s "magickými dlouhými cestami" neumí stejně pracovat.

PS: Pamatuju, jak jsem kdysi někomu pří upgradu počítače zazálohoval stará data z WinXP k sobě na disk, vynuloval MBR, naistaloval nově zakoupené Win7 a po té, co doběhla instalce a několikahodinová aktualizace, jsem nahrádl zazálohované data zpět s tím, že si je má dotyčný projít a co nebude chtít, ať smaže. Za tři dny mi volal, že data už prošel, ale nemůže smazat adresář se zbytkem starých Win XP. Až na místě jsem zjistil, že jedna z aplikací z původních WinXP měla tak rozmařile dlouhá jména adresářů a souborů, že po "zahloubení" do "Plochy" přesáhla délka cesty maximální limit. Než hledat na webu nějaký udělátor, co by to uměl smazat, raději jsem nabootovat z flashisku System Rescue CD a smazat to z Linuxu

[R]

Ten limit s dlzkou cesty je na zabitie. Da sa to prekrocit aj pri praci priamo vo Windows a potom to robi zahadne chyby typu subor sa ulozil, ale nejde uz otvorit...

[R]

A este rezervovane slova.

Skusme vytvorit subor :D

char path[] = "c:\test\con";
FILE *f = fopen(path, "w");

[:::]

teda tomu rikam megaprasarna

[Jardík]

Však ono to taky jde, když použite tu úplnou cestu s prefixem "\\?\". Ale nevím, jestli to ten fopen sežere správně.

[kutr]

Blog plete dohromady 2 nesouvisející věci. Vnitřní reprezentaci cesty k souboru a její konverzi pro konkrétní platformu. Logicky, pokud to někdo matlá dohromady, tak dřív nebo pozdějc udělá chybu. Nepřijde mi divný interně používat jen jedno lomítko. Stejně tak mi nepřijde divný používat interně stejný typ kódování pro stringy nebo stejný odřádkování. Je milión věcí, který se lišej, tak mi přijde blbost to dělat všechno sám, když už to za mě někdo vyřešil v multiplatformní knihovně.

[Jardík]

Ono by stačilo, kdyby to Qt nevracelo pokaždé jinak. Nevidím v tom, kromě obyč stringu udělat třídu třeba QFileName nebo QPath či něco takového, kde budou metody třeba jako up(), cd(QString), či něco podobného a vnitřně to stále bude jako QString, ale s nativními lomítky. Uživatel by se pak o to vůbec nemusel starat a bylo by to správně i pro použití nativních api.

[Sten]

Doporučuji si nejdřív začít stěžovat na aplikace, které nezvládnou soubory „.“ a „..“, které také lze na NTFS vytvořit.