Találós kérdés

Offtopic

Ma konzolból cd írási szándékkal kiadtam a következő parancsot:

mkisofs -V "$lemezcimke" -J -R -iso-level 3 "$fajlnev" | cdrecord -driveropts=singlesession -v speed=8 dev=0,0,0 -

A $fajlnev fájl vagy 700M-ás, és 24 órai kódolás eredménye.

5 másodperccel a fenti cd író parancs kiadása után a fájlt véletlenül töröltem a konquerorban; eltűnt az adott könyvtárból, még mielőtt a cdrecord egy bájtot is a cdre írt volna.

Egy találós kérdésem volna hozzátok: a fentiek ismeretében szerintetek végig ment-e és sikeres volt-e a cdírás?

  • 1770 megtekintés

( Csigaa | 2006. 03. 19., v – 18:16 )

Olvasd végig figyelmesen amit TE MAGAD írtál. Szerinted ez alapján lehetséges??

Némi kétkedést érzek ebben a kérdésben.
Próbáld ki: elkezdesz egy file-t dd if=/dev/zero of=x.x formában írni. Mikor már elég nagy a file ahhoz, hogy pl. a df kimenetén látható nyomot hagyjon a hiánya
- nézd meg a szabad helyet
- töröld a file-t anélkül, hogy a dd-t kilőnéd
- nézd meg ismét a szabad területet
Ha jól érzem, meg fox lepődni ;-)

( drojid | 2006. 03. 19., v – 18:20 )

Sikeres volt, hiszen amíg használatban van a file, addig nem törlődik fizikailag, csak miután az írás befejeződött.

Talált?

( snq- | 2006. 03. 19., v – 18:53 )

>> Egy találós kérdésem volna hozzátok: a fentiek ismeretében szerintetek végig ment-e és sikeres volt-e a cdírás?

nagy valószínűséggel igen, és akár még "vissza is hozhattad" volna, mielőtt befejeződik az írás

( antiemes | 2006. 03. 19., v – 19:36 )

Hi!

Nem biztos, hogy sikeres volt, de igen valoszinu. Ugyanis az mkisofs megnyitja a filet, rogton a parancs kiadasakor, es egeszen a file lezarasaig nem torlodik. Ez az 5 mp azert kavarhat be, mert a cdrecord alapban 9 mp-et var az iras elott, de ezt az mkisofs nem tudja, az mar szolgaltatja is az adatokat neki. Szoval ha pl. tettel be lemezt, nem ment el az aram stb, akkor kiirta a file-t.

By(t)e
TBS::Antiemes

( j_szucs | 2006. 03. 20., h – 10:33 )

drojid, snq-, antiemes talált: a menet közben törölt fájl cd-re írása sikeres volt :-)

A dolog technikai hátterét nem ismerem annyira, hogy megítéljem, melyikőtök magyarázata áll a legközelebb az igazsághoz.

De mindenesetre érdekes (és szerencsés) jelenség volt :-)

"melyikőtök magyarázata áll a legközelebb az igazsághoz"
Mivel ugyanazt irtuk, a mi magyarázatunk áll hozzá a legközelebb ;-)

Semmivel nem érdekesebb egyébként, mint pl az, hogy ha egy programmal elkezdesz írni egy filet, akkor (pl a vindózzal ellentétben) egy másikkal rögtön tudod olvasni azt, egyszerűen így működik és kész :-) (megjegyzem, logikusan)

( egmont | 2006. 03. 20., h – 12:48 )

Én rendszeresen csinálok olyat, hogy amint a bladeenc elkezdi
tömöríteni az egyik wav-ot, azt rögtön kitörlöm. Műxik szépen.
Persze fizikailag csak a tömörítés végeztével törlődik a fájl,
addig df-ben látszik a helyfoglalása stb., de legalább tuti hogy
nem fogom elfelejteni letörölni.

( gsimon | 2006. 03. 20., h – 13:03 )

Amíg akár egyvalaki is nyitott filehandle-t tart a file-ra, addig annak csak a neve tűnik el, maga a file létezik és marad. Példának okáért fogj egy szövegfile-t (pl. logot), nyiss rá egy 'less'-el, majd töröld másik konzolról a file-t. A szabad hely nem változik.
Sőt mi több, ha megkeresed a less process-id-jét, és lemégy a /proc/PID/fd-be, akkor ott még rá is tudsz nyitni mással, akár el is tudod másolni! 


fules@chaos:/tmp$ ps -fC less
UID        PID  PPID  C STIME TTY          TIME CMD
fules     2146  2126  0 12:58 pts/16   00:00:00 less /tmp/ize.log
fules@chaos:/tmp$ ls -l /proc/2146/fd
total 5
lrwx------  1 fules fules 64 Mar 20 12:58 0 -> /dev/pts/16
lrwx------  1 fules fules 64 Mar 20 12:58 1 -> /dev/pts/16
lrwx------  1 fules fules 64 Mar 20 12:58 2 -> /dev/pts/16
lr-x------  1 fules fules 64 Mar 20 12:58 3 -> /dev/tty
lr-x------  1 fules fules 64 Mar 20 12:58 4 -> /tmp/ize.log (deleted)
fules@chaos:/tmp$ cp /proc/2146/fd/4 hoze.log
fules@chaos:/tmp$ ls -l hoze.log 
-rw-r--r--  1 fules fules 181529 Mar 20 13:00 hoze.log

Nem egyszer 'mentettünk' már meg véletlenül törölt file-t ezen a módon :)...