Administrace komentářů

A ty víš, že je to na jednom filesystému? Ne? Takže irelevantní argument.

O tom, že na různých systémech jsou různé nestandardní přepíánače vím, ale pokud řeším problém a není specifikovaný systém, tak se držím POSIX normy: http://www.unix.com/man-page/POSIX/0/mv/ a v té tento přepínač není.

Takže ho stačí přesunout do správného adresáře? WTF? A kde máš zajištěno, že v tom adresáři už soubor se stejnym názvem neni? Kde máš řečeno, že ten soubor nevzniknul např. voláním mktemp, který samozřejmě může vytvořit soubor se stejným názvem dvakrát, pokud první mezi tím zmizí? Navíc si chtěl v názvu souboru uchovávat informace, jak víš, že v tom zdrojovym názvu jsou a ve formě jak je potřebuješ? A jak víš, že soubory nepocházejí z více zdrojů? Atd.... Jinými slovy: ano, pokud mu něco vytváří unikátní soubory, má problém s unikátností souborů vyřešen. Je to někde v zadání? Ne? Opět si tedy zadání ohýbáš, jak se Ti hodí. A i kdyby bylo, tak stejně je to věc, kterou ve FS musíš ověřovat, že tomu tak opravdu je, zatímco v DB to prostě nemusíš řešit.

Všiml sis, že tady už pěkně dlouho řešíme tu úplně nejtriviálnější věc: spolehlivé založení souboru. To, co se v DB udělá jedním insertem a není tam jediný problém? Zatímco tady furt řešíme jak co je a není atomické (a vidno úplně triviální to není), vede to k užití nepřenositelných přepínačů (navíc pak tam musíš mít test a další řešení co když se to nepovede, takže složitější kód), kolega navrhl zas řešení, které není odolné výpadku a má i další chyby... Proč bych se tím měl zatěžovat? Abych pak mohl použít standardní nástroje jako find a grep, když databáze mi nabízí na vyhledávání daleko efektivnější nástroje? Nebo perl, kterému je úplně šumák, odkud data dostane?

PS: ...chyby: např. když zároveň vedle poběží analyzátor, tak může spadnout na nekompletním XML, protože přečte soubor dřív než je dokopírován (i mv je atomické pouze na jednom FS a zaručeno není).