kis teszt:
oscar@shelob:~/tmp$ echo bela >aa
oscar@shelob:~/tmp$ strace -e write,read tar cf aa.tar aa
read(3, "\177ELF\1\1\1\0\0\0\0\0\0\0\0\0\3\0\3\0\1\0\0\0`\35\0\000"..., 512) = 512
read(3, "\177ELF\1\1\1\0\0\0\0\0\0\0\0\0\3\0\3\0\1\0\0\0\240O\1"..., 512) = 512
read(3, "\177ELF\1\1\1\0\0\0\0\0\0\0\0\0\3\0\3\0\1\0\0\0\360G\0"..., 512) = 512
read(4, "bela\n", 5) = 5
write(3, "aa\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0"..., 10240) = 10240
Process 5809 detached
oscar@shelob:~/tmp$
Latszik, hogy beolvasta es kiirta a fajl tartalmat.
oscar@shelob:~/tmp$ strace -e write,read tar cf /dev/null aa
read(3, "\177ELF\1\1\1\0\0\0\0\0\0\0\0\0\3\0\3\0\1\0\0\0`\35\0\000"..., 512) = 512
read(3, "\177ELF\1\1\1\0\0\0\0\0\0\0\0\0\3\0\3\0\1\0\0\0\240O\1"..., 512) = 512
read(3, "\177ELF\1\1\1\0\0\0\0\0\0\0\0\0\3\0\3\0\1\0\0\0\360G\0"..., 512) = 512
Process 5803 detached
Hmm... Ez bizony nem irta ki a cuccot sehova!
Viszont a fajlt lathatoan beolvasta.
Lassuk mit tesz a FreeBSD tar, amit Debianon a bsdtar csomagban talaltam:
oscar@shelob:~/tmp$ strace -e write,read bsdtar cf aa.tar aa
read(3, "\177ELF\1\1\1\0\0\0\0\0\0\0\0\0\3\0\3\0\1\0\0\0\340\26"..., 512) = 512
read(3, "\177ELF\1\1\1\0\0\0\0\0\0\0\0\0\3\0\3\0\1\0\0\0\340\20"..., 512) = 512
read(3, "\177ELF\1\1\1\0\0\0\0\0\0\0\0\0\3\0\3\0\1\0\0\0\240O\1"..., 512) = 512
read(7, "\177ELF\1\1\1\0\0\0\0\0\0\0\0\0\3\0\3\0\1\0\0\0\200\4\0"..., 512) = 512
read(6, "bela\n", 65536) = 5
read(6, "", 65536) = 0
write(3, "aa\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0"..., 2048) = 2048
Process 6107 detached
oscar@shelob:~/tmp$ strace -e write,read bsdtar cf /dev/null aa
read(3, "\177ELF\1\1\1\0\0\0\0\0\0\0\0\0\3\0\3\0\1\0\0\0\340\26"..., 512) = 512
read(3, "\177ELF\1\1\1\0\0\0\0\0\0\0\0\0\3\0\3\0\1\0\0\0\340\20"..., 512) = 512
read(3, "\177ELF\1\1\1\0\0\0\0\0\0\0\0\0\3\0\3\0\1\0\0\0\240O\1"..., 512) = 512
read(7, "\177ELF\1\1\1\0\0\0\0\0\0\0\0\0\3\0\3\0\1\0\0\0\200\4\0"..., 512) = 512
read(6, "bela\n", 65536) = 5
read(6, "", 65536) = 0
write(3, "aa\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0"..., 10240) = 10240
Process 6111 detached
Nincs kulonbseg a /dev/null es a rendes tar fajl eset kozt.
Ez annak ekes bizonyiteka, hogy a GNU az nem UNIX :)
Sikerult egy regota adott modon mukodo dolgot _szerintem_ nagyjabol celtalanul megvaltoztatni. Hogy aztan azok akik UNIXot szoktak hasznalni, csak lessenek miert nem mukodik ugy ahogy megszoktuk.
Eljen.
- uid_1062 blogja
- A hozzászóláshoz be kell jelentkezni
- 1376 megtekintés
Hozzászólások
Nem 'céltalan', és a végeredmény _ugyanaz_.
1995-12-21 François Pinard <pinard@iro.umontreal.ca>
...
Corrections to speed-up the sizeing pass in Amanda:
* tar.h: Declare dev_null_output.
* buffer.c (open_archive): Detect when archive is /dev/null.
(flush_write): Avoid writing to /dev/null.
* create.c (dump_file): Do not open file if archive is being
written to /dev/null, nor read file nor restore times.
Reported by Greg Maples and Tor Lillqvist.
...
- A hozzászóláshoz be kell jelentkezni
Rendben nem celtalan, de nem vagyok meggyozve, hogy ez feature nem lett volna jobb helyen pl egy kapcsoloban.
Ez egy eleg komoly elteres a tobbi tar viselkedesetol.
A vegeredmeny meg nem egeszen ugyanaz. Az adat nincs kiirva a /dev/nullba.
- A hozzászóláshoz be kell jelentkezni
A /dev/null ba nincs értelme irni.
A végeredmény ugyanaz: a nagy semmi.
A különbség eszerint akkor abban van ahogy ezt a nagy semmit elérik.:)
Az egyik semmit nem csinál a semmiért, a másik pedig mindent megcsinál,
hogy elérje a nagy b*d*s semmit.:))
- A hozzászóláshoz be kell jelentkezni
kettovel lejjebb egy pelda arra, hogy ez zavart tud okozni.
Kulonosen mivel a manban nincs benne.
- A hozzászóláshoz be kell jelentkezni
Aláirom, igazad van.
Tényleg zavaró lehet.
Nincs is ezen mit vitatkozni.
- A hozzászóláshoz be kell jelentkezni
Egy kis javítás..
> Hmm... Ez bizony nem irta ki a cuccot sehova!
> Viszont a fajlt lathatoan beolvasta.
.. a második esetben nem volt tényleges "beolvasás" a memóriába, mivel a "bela/n" nem jelent meg sehol.
"Ez annak ekes bizonyiteka, hogy a GNU az nem UNIX :)"
Ezzel csak az a bajom nekem (mint talán imp-nek is), hogy nézőpont kérdése mi céltalan és mi nem.
A /dev/null-bol nincs értelme olvasni, viszont ha ezt megforditjuk nincs is értelme irni bele.. ha logika
alapján nézem, akkor a linux-os tar jol mukodik.. ha a következetességet nézem a bsds-tar müködik jól.. nekem
a logikus a szimpatikusabb megközelítés.
Fri
- A hozzászóláshoz be kell jelentkezni
AAAAaaaaa...
Eszembe jutott miert szivtam en ezzel mar egyszer...
Lassuk a kovetkezo peldat:
oscar@shelob:~/tmp$ time tar cf - test.100M | cat > /dev/null ; time tar cf /dev/null test.100M
real 0m0.228s
user 0m0.023s
sys 0m0.205s
real 0m0.002s
user 0m0.001s
sys 0m0.001s
Az elteres abbol adodik, hogy meg csak vegig sem olvasta a fajlokat. Koszonom a korrekciot :)
Azt akartam egyszer regen megnezni, hogy mennyi ideig fut majd a backup scriptem.
Csak helyem nem volt meg hozza. S total hulyesegeket kaptam... Merthogy a devnullba irva nem is olvasunk. Meg nem is irunk.
Koszonom a megfejtest.
- A hozzászóláshoz be kell jelentkezni
logikus, nem logikus... Ha egy UNIX jellegu kornyezetet hasznalok, akkor nekem az a logikus (tudom nem logikus csak konform), ha ugyanugy viselkedik a ket ugyanolyan nevu alkalmazas.
tar cf /dev/null /data
gnutar cf /dev/null /data
nem ugyanazt csinalja. Es nincs benne a manualban.
Nem szandekozom ertekelni, eldonteni, hogy ki az okos. Teljesen erdektelen.
Az szamit, hogy vegre valahara megtudtam, elteroen mukodnek.
- A hozzászóláshoz be kell jelentkezni
>ket ugyanolyan nevu alkalmazas
>tar cf /dev/null /data
>gnutar cf /dev/null /data
^^^nem ugyanolyan ;-)
- A hozzászóláshoz be kell jelentkezni
Megall a fejlodes adott fokan? csak, hogy ugyanugy viselkedjen.
A tar kapcsoloi is kevesebben vannak, mint a gnu valtozate.
A tar esetleg megall 2GB korlatnal, amit a gnu atlep...
Amelyik rendszer a pax-ot ajanlja tar helyett, az vajon miert teszi?
- A hozzászóláshoz be kell jelentkezni
tar cf /dev/null /dev/hda
gnutar cf /dev/null /dev/hda
Na, melyik végez előbb?
Egyáltalán nem értem, miért lenne jó, ha ugyanazt csinálná. Minek végigolvasni jónéhányszor 10 GiB adatot, ha egyből azt lehet mondani, hogy oké, most ez a /dev/null-ba megy, ezért már ki is lép. Sőt, a bash-be minek beépített test, [, [[, :, stb, ha minden ott van a /bin-ben? Egyáltalán, minek fejleszteni bármit is? Jó az X éves megoldás, nem?
- A hozzászóláshoz be kell jelentkezni
Harommal feljebb ott az indoklas miert lehet ez problema adott esetben.
olvassatok mar.
osszekevertek dolgokat.
Nem a fejlodes ellen beszeltem. Az ellen, hogy megszokott, bevett modon mukodo dolgokat figyelmeztetes nelkul valtoztatnak meg.
Nem extra feature hozzaadasarol (plusz kapcsolok), nem hianyossagok kijavitasarol (large file support), nem bugok javitasarol. Hanem a viselkedes alapveto megvaltoztatasarol (ha /dev/null a cel nem is olvassuk be es nem is irjuk ki a fajlt), dokumentacio nelkul (a forras es a changelog nem szamit dokumentacionak).
Arrol, hogy egy bizonyos kimeneti fajlt maskeppen kezelnek mint a tobbit, es errol nem tud az ember changelog, forras vagy strace ellenorzes nelkul.
Egyebkent sem kell "megvedeni" a gnu tart... Nem haragszom ra. Es tovabbra is azt fogom hasznalni. Most legalabb tudom, hogy miert nem olvassa vegig a CDt vagy akarmit amikor ellenorzes gyanant a /dev/nullba irok.
A peldad egyebkent mirol szol? az eszkozfajlokat egyebkent is csak akkent menti, nem a tartalmukat. Szoval a kulonbseg minimalis.
oscar@shelob:~$ time tar cf - /dev/sda | cat > /dev/null; time tar cf /dev/null /dev/sda
tar: Removing leading `/' from member names
real 0m0.002s
user 0m0.000s
sys 0m0.002s
tar: Removing leading `/' from member names
real 0m0.001s
user 0m0.001s
sys 0m0.000s
oscar@shelob:~$
- A hozzászóláshoz be kell jelentkezni
Mondjuk nem értem, hogy miért hivatkoznak az úgy Amandára, mintha azt mondanák:
-öööhhát a főnöknek kellett...
-ja akkor már értem
De nem ez az egyetlen furcsaság..
$ man tar
BUGS
The GNU folks, in general, abhor man pages, and create info documents instead. [...]
If you really want to understand tar, then you should run info and read the tar info pages, or use the info mode in emacs.
És lám:
$ info tar
When the archive is being created to `/dev/null', GNU `tar' tries to
minimize input and output operations. The Amanda backup system, when
used with GNU `tar', has an initial sizing pass which uses this feature.
- A hozzászóláshoz be kell jelentkezni
Yeeehaaaaaw...
Ezt most megprobalom bevesni az eszembe.
Kar, hogy az info egy ronda dog.
- A hozzászóláshoz be kell jelentkezni
Elismerem, nem próbáltam ki, meg ha végiggonolom: nem is menne, csak a dd-vel kapott másolattal. Na és erre gondoltam (mivel a másolatról kellene visszaszednem adatokat, de nem megy) :S
- A hozzászóláshoz be kell jelentkezni
"Egyáltalán, minek fejleszteni bármit is? Jó az X éves megoldás, nem?"
Eszembe jutott meg valamit...
fejlesztes != valtoztatas
Ha valami jol mukodik, es regi azt nem kell megbolygatni csak azert mert _regi_.
A fejlesztes az elore mutat (large file support, --devnull kapcsolo). Ez a valtoztatas peldaul az en esetemben problemat is okozott.
Aligha nevezheto "fejlesztesnek", amikor egy bizonyos alkalmazas (amanda) kedveert valamit megvaltoztatnak. Mikozben mas hasznos hasznalati modjai az alkalmazasnak kart szenvednek.
Peldaul ezen a ponton eszemben nincsen egy bugreportot leadni a gtar fejlesztoinel errol a viselkedesrol. 95 ota igy van.
Emberek ezrei szoktak meg a viselkedeset. Ha atirnak (veletlenul) az en szam ize szerint az csak _valtoztatas_ volna nem fejlesztes.
Talan bugfix de ez meg nezopont kerdese. Az embereknek akik igy szoktak meg, ez egy uj bug lenne...
De asszem ez mar lassan metafizikai melysegu lesz :-D
Hagyjuk.
Jo a gtar ahogy van, en meg orulok, hogy vegre tudom a cd ellenorzo quickie-m (tar cf /dev/null /mounts/cd0) miert nem mukodott rendesen Linux alatt.
- A hozzászóláshoz be kell jelentkezni
a peldaidban tobbnyire eszkozoket tomsz a null-ba.
dd-vel olvass, tar-ba csovezz es minden szepen megy.
tobbletmunka, de megterul ;)
- A hozzászóláshoz be kell jelentkezni
Az nem az en peldam volt :)
- A hozzászóláshoz be kell jelentkezni