Jak je to s časem vzniku souboru na GNU Linux distribucích (diskuse)

[Bedňa]

Vieme o tom 1 - 2.

[marbu]

Ten článek čtenáře ze začátku napíná, jako kdyby se čas vzniku souboru dal z klasické trojice unixových časů přečíst :)

Toto správanie je však možné zmeniť, čím ale dôjde k porušeniu POSIX-u a niektoré aplikácie kvôli tomu nemusia pracovať správne.

Kromě věcí typu dump, co jiného nebude fungovat správně, když mám připojený souborový systém s volbou relatime? Vzhledem k tomu, že realtime je default snad všude a existují volby jako noatime, nevím co by se mělo s realtime rozbít.

Ak sa však pozrieme do histórie, hodnota ctime naozaj reprezentovala čas a dátum vytvorenia súboru (z angl. Creation Time). Postupne sa však z tejto hodnoty stala hodnoty času poslednej zmeny vlastností súboru tak, ako ho poznáme dnes.

Jinak jak píšu v blogu, tohle není pravda.

[Bedňa]

Ja som myslel tie moje komentáre pod článkom, kde som sa to snažil osvetliť.

[marbu]

Ah, ok. Na jednu stranu je trochu škoda, že se to tenkrát zaseklo (to Linusovo "Let's wait five years and see" si z jaderných novinek taky pamatuju), ale na druhou stranu ho zcela chápu. Do Linux api nejde přidávat hned každou blbost :)

[Gilhad]

Ono je to hlavně filosofický problém - pokud mám řekněme delší text, co jsem začal psát předloni a letos ho rozdělím do deseti kapitol, tak se ty kapitoly zrodily převážně loni, ctime bude teď a co jako má ten birthtime vlastně vůbec znamenat?

- čas, kdy jsem začal kapitolu psát? tedy nějaké loňské datum?

- čas, kdy jsem začal psát ten traktát? tedy předloni?

- čas, kdy jsem ten soubor uložil pod novým jménem? tedy teď? A co když ho zítra přejmenuju z c7.txt na popisnější ch_07_co_je_čas.txt?

- čas, kdy se vlastně ta myšlenka popsaná v té kapitole zrodila? U mě před třemi lety, ale o podobné věci už debatovali staří řekové a římané, tedy spíš někde kolem začátku letopočtu?

Imho jediný rozumný čas je to, co uvedu přímo v textu toho souboru, ostatní možnosti většinou nedávají dobrý konzistentní smysl - kdy to bylo naposled modifikované a kdy ten konkrétní soubor na tom filesystému vzniknul už stejně máme...

[marbu]

Ono ta btime značka mi vzhledem k její nízkoúrovňové povaze přijde pro běžného uživatele na pokraji použitelnosti.

Ale ten tvůj příklad je něco, co lze pěkně řešit pomocí gitu. Začnu psát a postupně dělám commity když dokončím nějaký dílčí celek textu. Ten může růst a přesovat se mezi soubory, ale všechny informace, na které se ptáš, jdou přes git získat zpětně. A až na případ s rozdělením jednoho souboru do 10 menších a ten filosofický případ s Řeky a Římany dokáže git dát odpověď dohromady zcela automaticky :)

Viz. příklad z toho Unix history repa, kde je výstup z git blame:

3cc1108b usr/sys/ken/pipe.c     (Ken Thompson 1974-11-26 18:13:21 -0500  53) 	rf->f_flag = FREAD|FPIPE;
3cc1108b usr/sys/ken/pipe.c     (Ken Thompson 1974-11-26 18:13:21 -0500  54) 	rf->f_inode = ip;
3cc1108b usr/sys/ken/pipe.c     (Ken Thompson 1974-11-26 18:13:21 -0500  55) 	ip->i_count = 2;
[...]
1f183be2 usr/sys/sys/pipe.c     (Ken Thompson 1979-01-10 15:19:35 -0500 122) 	register struct inode *ip;
1f183be2 usr/sys/sys/pipe.c     (Ken Thompson 1979-01-10 15:19:35 -0500 123) 
1f183be2 usr/sys/sys/pipe.c     (Ken Thompson 1979-01-10 15:19:35 -0500 124) 	ip = fp->f_inode;
1f183be2 usr/sys/sys/pipe.c     (Ken Thompson 1979-01-10 15:19:35 -0500 125) 	c = u.u_count;
1f183be2 usr/sys/sys/pipe.c     (Ken Thompson 1979-01-10 15:19:35 -0500 126) 
1f183be2 usr/sys/sys/pipe.c     (Ken Thompson 1979-01-10 15:19:35 -0500 127) loop:
1f183be2 usr/sys/sys/pipe.c     (Ken Thompson 1979-01-10 15:19:35 -0500 128) 
1f183be2 usr/sys/sys/pipe.c     (Ken Thompson 1979-01-10 15:19:35 -0500 129) 	/*
9a9f6b22 usr/src/sys/sys/pipe.c (Bill Joy     1980-01-05 05:51:18 -0800 130) 	 * If error or all done, return.
9a9f6b22 usr/src/sys/sys/pipe.c (Bill Joy     1980-01-05 05:51:18 -0800 131) 	 */
9a9f6b22 usr/src/sys/sys/pipe.c (Bill Joy     1980-01-05 05:51:18 -0800 132) 
9a9f6b22 usr/src/sys/sys/pipe.c (Bill Joy     1980-01-05 05:51:18 -0800 133) 	if (u.u_error)
9a9f6b22 usr/src/sys/sys/pipe.c (Bill Joy     1980-01-05 05:51:18 -0800 134) 		return;
6d632e85 usr/sys/ken/pipe.c     (Ken Thompson 1975-07-17 10:33:37 -0500 135) 	plock(ip);
6d632e85 usr/sys/ken/pipe.c     (Ken Thompson 1975-07-17 10:33:37 -0500 136) 	if(c == 0) {
6d632e85 usr/sys/ken/pipe.c     (Ken Thompson 1975-07-17 10:33:37 -0500 137) 		prele(ip);
6d632e85 usr/sys/ken/pipe.c     (Ken Thompson 1975-07-17 10:33:37 -0500 138) 		u.u_count = 0;
6d632e85 usr/sys/ken/pipe.c     (Ken Thompson 1975-07-17 10:33:37 -0500 139) 		return;
6d632e85 usr/sys/ken/pipe.c     (Ken Thompson 1975-07-17 10:33:37 -0500 140) 	}

Imho jediný rozumný čas je to, co uvedu přímo v textu toho souboru, ostatní možnosti většinou nedávají dobrý konzistentní smysl

Souhlasím, pro uživatele jsou často zajímavější metadata datového formátu (ať už je to ten výše zmíněný git, nebo např. exif data ve fotce) než to, co ukládá souborový systém. To ale neznamená, že by to šlo z něj vyhodit.

kdy ten konkrétní soubor na tom filesystému vzniknul už stejně máme...

Moment, to je ten btime, o kterém jsem psal. Nebo jsem nepochopil, jak to myslíš.

[Xerces]

Nejprve musím pochválit autora za perfektní přehled. Moc dobře se to četlo i když člověk tušil jak to dopadne Jinak souhlasím s uživatelem Gilhad, že je to spíše filosofický problém. Stejně jako čas zrušení souboru se jedná o extrém, který podle mě nemá význam evidovat. Ostatně i závěr autora včetně uvedených důvodů v poslední kapitole to zmiňuje. Proč se tedy snažit implementovat něco takového, když by ten přínos nebyl jednoznačný?

[xkucf03]

Když už FS tu informaci ukládají, tak by to chtělo ji dotáhnout i do uživatelského rozhraní. (případně odmazat z implementací těch FS, třeba tam všude dávat nulu)

[xkucf03]

Díky za článek.

V anketě jsem dal „naprosto zásadní“ – ono to tedy většinou zásadní není, ale občas by to mohla být pěkná zrada a mohla by tímto kanálem prosáknout informace, která by prosáknout neměla. Z tohoto důvodu doufám, že budou brzo dostupné nástroje pro přepis této informace, aby to člověk nemusel hackovat přímým přepisováním příslušných bajtů na blokovém zařízení.

[Filip Jirsák]

Třeba cp?

[marbu]

Ano, ale není to vždy bez komplikací. Třeba pokud není dost volného místa na disku nebo u neprázdného adresáře, který není možné jednoduše přesunout (např. kdybych chtěl změnit btime u svého domovského adresáře).

[marbu]

Na druhou stranu prosáknutí hrozí jen pokud si někdo zajistí přístup k tvému souborovému systému, což se dá řešit např. šifrováním celého disku, protože na něm budou pravděpodobně i jiné zajímavé věci, než jen btime značky na souborech.

Btw z forenzního hlediska jsou imho nejzajímavější btime značky na adresářích.

Ale jinak souhlas, přístup co zvolilo FreeBSD mi přijde osobně rozumnější.

[danc]

Diky za skvele ctivy clanek! Jestli to tu jeste aspon trochu zije, bylo by hezke, kdyby tento text vysel na hlavni strance jako clanek a reakce poslala autorovi nejakou korunu

[Bherzet]

Nenapadlo by mě, že historie jednoho souborového atributu může být tak zajímavá. Díky za fakt pěkně zpracovaný článek.

Trochu OT, ale vzpomněl jsem si na otázku, kterou jsme kdysi řešili s kolegou: Co se stane při přenesení souborů (vč. atributů) na systém, kde je pod stejným UID jiný uživatel? Chtěl jsem to vyzkoušet, ale nějak to zapadlo a nedostal jsem se k tomu. Předpokládám, že se stane přesně to, co by se dalo čekat, tj. majitelem souboru bude uživatel s daným UID (bez ohledu na to, že třeba username se liší). Nedokážu si představit, proč by to tak být nemělo, takže druhá otázka pak je, jak tomu předejít. Umím si představit, jak to řešit technicky, ale přijde mi, že tohle je přesně věc, kterou lze velmi snadno přehlédnout a pak se chvíli divit, co se děje. Možná zálohovat i /etc/passwd a při obnovování ověřit, že na cílovém systému danému UID odpovídá stejný uživatel (resp. username)? Umí to nějaký standardní nástroj?

[xkucf03]

V rámci jedné organizace bývá obvykle snaha, aby jeden uživatel měl všude stejné UID (je na to např. atribut v LDAPu).

Připojovat někam cizí disk není úplně typický scénář a na výměnných médiích (diskety, USB flash…) býval většinou FAT, u kterého si vlastníka/práva zadáš při připojování. Ale když někam připojíš třeba záložní HDD s Ext4, tak se může stát, že než se rozkoukáš, už jiný uživatel z toho disku čte, protože má náhodou stejné UID jako třeba ty na jiném počítači… to už problém je. Tam musíš dát adresář, kam připojuješ, do adresáře, kam ostatní nevidí, a pak zkontrolovat práva a případně změnit vlastníky.

[Bherzet]

V organizacích asi jo, ale že mám na svých systémech všude stejný UID je v podstatě náhoda. Vím, že bych na to měl myslet, ale prostě mám vždycky nepříjemný pocit, když narazím na něco podobného (kolik času už jsem strávil debugováním i daleko zjevnějších omylů…). Stejně teď budu muset nějak „zrefactorovat“ a dořešit zálohování, tak si říkám, že bych fakt mohl přidat ten /etc/passwd (i k nesystémovým zálohám) a skript na obnovení, který to rovnou diffne proti aktuálnímu a upozorní na nesrovnalosti… To není tolik práce navíc a obnovovací skript (nebo nějaké README) chci mít na záloze asi stejně.

[Bherzet]

(Protože jakmile bych překopíroval hromadu souborů do nějaké existující adresářové struktury, tak opravovat potom ty práva všude by byl fakt opruz. U jednoho souboru/adresáře by to ani nestálo za řeč.)

[Gilhad]

závisí na způsobu přenosu - vyhledej si u rsync parametr --numeric-ids ten se právě tímnto zabývá (defaultně se kopíruje tak, aby zůstalo zachováno jméno (nikoli id) uživatele a skupiny, ale jsou různé problémy okolo toho)

[marbu]

Tohle je vlastně speciální případ. Při kopírování souboru se UID zachová pouze pokud běží pod rootem a řekneš si o to (např. přes cp -a, rsync -a nebo při rozbalování tarballu). Což se běžně děje např. při obnovoání záloh. A ano, majitelem souboru bude uživatel s daným UID bez ohledu na to, že třeba username se liší.

Btw gnu tar tohle nějak řeší, protože ukládá jak UID tak jméno (viz volby --no-same-owner, --numeric-owner, --owner=NAME[:UID], --owner-map=FILE).

Já svých strojích vytvářím uživatele ansible playbookem a zálohuju jen celý /home. Takže postup obnovení je spustit playbook a pak přes rsync zkopírovat celý /home.

[Václav HFechs Švirga]

Hlasoval jsem špatně (druhá volba, spíš jsem měl hlasovat pro třetí).

Využil jsem birth date pro jeden ošklivý workaround na jednom starším serveru. Běží na něm aplikace, kde jde přes apache+php uploadovat nějaké soubory a frontend přes sessions zobrazuje progres uploadu. Verze apache co tam běží (či PHPka) měla nějaký bug, že když byl soubor větší tuším více než 2 GB, session od té velikosti začala vracet nesmysly o velikosti uploadovaného souboru (přetekl nějaký int), upload ale po čase správně doběhl.

Provizorně se to zalepilo hackem (časem to nejspíš vyřeší aktualizace serveru), že pokud byl soubor větší než 2 GB, session se ignorovala a přímo se zjišťuje velikost souboru v /tmp. Problém byl najít správný soubor (název se dá zjistit až po doběhnutí uploadu). Ne úplně spolehlivá detekce (kdyby bylo více uploadů v jeden čas, nebude to fungovat, ale to se příliš neděje + upload tak velkých souborů není častý + způsobí to jen nefunkčnost progresu) funguje tak, že se projedou všechny tmp soubory odpovídající masce a najde se ten, který má nejbližší čas vytvoření od začátku uploadu.

Filesystém byl naštěstí ext4, tak se to naprasilo přes debugfs (skript, který user s aplikací schopný spustit přes sudo).

[debian+]

Autorovy a vsetkym: https://lwn.net/Articles/397442/

[marbu]

Však ano, tento článek z roku 2010 je nejlepší popis btime, co na lwn.net vyšel. Linkuju ho v blogu hned třikrát, z toho poslední link je v závěrečném přehledu, včetně českého překladu, co vyšel tady na abclinuxu v rámci jaderných novinek.

[marbu]

Btw časovou značku pojmenovanou btime v Linuxu najdeme ještě v /proc/stat, kde ale znamená boot time, tj. čas kdy systém nabootoval, v unixovém formátu se sekundovou přesností:

$ grep btime /proc/stat
btime 1550868084
$ grep btime /proc/stat | awk '{ print "@"$2 }' | date -f- 
Fri Feb 22 21:51:24 CET 2019

[uruk]

Po začištění hran:

$ awk '$1 == "btime" {print strftime("%FT%T",$2)}' /proc/stat
2019-02-21T14:02:24

[marbu]

Malý update: ten patch pro stat se po několika malých úpravách nakonec dostal do upstreamu. Viz. sekce Improvements v oznámení o vydání GNU coreutils verze 8.31.