rc.conf
Jan Pechanec
jp at devnull.cz
Mon Dec 3 23:48:30 CET 2012
On Mon, 3 Dec 2012, Dan Lukes wrote:
>> Pavel si stezoval, ze mu ten soubor zmizi uplne, coz je jina
>> kategorie problemu :-)
>
> Na tom filesystemu jsou stovky souboru. Jen u tohohle je ale hlaseni uz druhe
> zmizeni. Nejak se ten soubor od tech ostatnich musi lisit.
>
> Ja bych hypotezy, ze to nejak souvisi s tim, ze soubor byl nedlouho pred padem
> editovan tak snadno nevzdaval. Nicmene, nevime zda byl editovan a pokud ano,
> jak presne onen konkretni editor editaci provadi. Treba tam ten soubor nekde
> je, jen pod jinym jmenem - protoze behem abendu se neulozilo to, jak ho editor
> prejmenovaval zpet na jeho puvodni jmeno a misto ...
>
> Coz nic nemeni na tom, ze je to stale jen hypoteza.
moznost to je, divam se, co dela treba vim pri zapisu, a ten to dela
obracene, nejdriv prejmenuje puvodni soubor na <filename>~ a pak zapise cely
data do nove vytvorenyho souboru s puvodnim jmenem (pridaval jsem "x\n" do
souboru s "xxx\n"):
unlink("output~") Err#2 ENOENT
rename("output", "output~") = 0
open64("output", O_WRONLY|O_CREAT|O_TRUNC, 0600) = 4
write(4, " x x x\n x\n", 6) = 6
fdsync(4, FSYNC) = 0
stat64("output", 0xFEFFDB68) = 0
stat64("output", 0xFEFFDA14) = 0
close(4) = 0
...
unlink("output~") = 0
pak mazne ten <filename>~. Kazdopadne ten soubor v jednu chvili
neexistuje pod puvodnim jmenem, coz muze byt ta situace, do ktere se po padu
system vrati.
pri pouziti vimu by tedy urcite stalo za to se podivat, zda existuje
swap file.
p.
--
Jan Pechanec <jp (at) devnull (dot) cz>
http://www.devnull.cz
More information about the Users-l
mailing list