Dotaz: KDE a kopirovani souboru pres smb

[Leshy]

Ahoj, mam problem. Kdyz kopiruju v konqueroru nebo i krusaderu nejake soubory pres smb protokol na server, tak se kopiruji prehazene - uvedu na prikladu.
Mam adresar s pisnickama 01 xxx.mp3 az treba 15 xxx.mp3. Kdyz adresar otevru, oznacim soubory a dam kopirovat, kopiruji se pekne serazene. Kdyz ale adresar neotevru a dam ho kopirovat cely, tak to kopiruje v nahodnem, ale vzdy stejnem, poradi.
Nevite jestli se to da nejak nastavit, aby mi to kopirovalo vzdy serazene? Problem se vyskytuje jen pri uploadu na server pres smb. Kdyz kopiruju na localnim disku, tak je to v pohode, kdyz stahuju ze serveru, tak taky.

System gentoo, kde 3.5.8 a zbyle info dodam az si o nej reknete :). Dik.

Odpovědi

[Leshy]

Nikdo nevi, jestli se to da nastavit?

[Leshy]

Takze, mam tu novinku :)
Trochu jsem vas mystifikoval, ono to totiz nefunguje ani na lokalnim disku. Za vsemi problemy stoji pravdepodobne cp. A tim se tedy dostavame k nove otazce (a jestli na ni nikdo neodpovi, tak z toho udelam novej dotaz s lepsim nadpisem ).
Podle ceho cp urcuje poradi souboru v adresari, ktere bude kopirovat? To same dela i 'find .', ten soubory vypise stejne jak je cp kopiruje. Vim, ze to neni podle atime, mtime, velikosti a ani podle abecedy. A zadne jine kriterium uz me nenapada...

./04 - Neni Potreba.mp3
./05 - Slapeme Si.mp3
./15 - Divenka.mp3
./12 - Dokolo, Dokola....mp3
./02 - Zvoni.mp3
./11 - Telefon.mp3
./07 - Melodram.mp3
./10 - Bynda.mp3
./08 - Hrdlo Prdlo.mp3
./09 - Kaluz.mp3
./13 - Balada.mp3
./03 - Potvory.mp3
./01 - Bouda.mp3
./16 - Mate na to.mp3
./06 - Vila.mp3
./14 - Cert.mp3

Tohle je treba vypis findu, podle velikosti je to uplne jinak a atime a mtime jsou pekne od 01 do 16. Ale treba hned ve vedlejsim adresari mi to vypisuje pekne serazene - tam teda nemam mezery v nazvu souboru. Tipuje ale, ze na to nemaji vliv, i kdyz radsi to jeste testnu.

[Ash]

No je to ctime (vizte níže). Ale ten FS zpravidla neuchovává, proč taky.

[Ash]

Přesněji, aby někdo neremcal, je to "jako ctime", samozřejmě se tam nic neřadí nebo tak, jde jen o to že v tom pořadí (pořadí v jakém byly soubory v adresáři vytvořeny) jsou záznamy v adresáři fyzicky uložené.

[Ash]

Hm, vlastně nebude, pokud nejde zrovna o FATku :) U většiny linuxových FS to bude asi opravdu těžko odhadnutelné pořadí.

[Ash]

Zkuste ls -lU (long unsorted) , mohlo by to hodit toto pořadí.

[Leshy]

Ano, to hodi poradi, jake jsem napsal vyse, ale...
Ta teorie s tim vytvorenim mi moc nesedi. Protoze kdyz soubory potom prejmenovavam, tak se najednou zacinaji nejak zahadne radit - nevidim v tom logiku.

./15 - Divenka.mp3
./12 - Dokolo, Dokola....mp3
./11 - Telefon.mp3
./13 - Balada.mp3
./10-Bynda.mp3
./16 - Mate na to.mp3
./01.mp3
./02.mp3
./03.mp3
./04.mp3
./05.mp3
./09-Kaluz.mp3
./06Vila.mp3
./08-Hrdlo Prdlo.mp3
./07Melodram.mp3
./14 - Cert.mp3

Treba takhle to vypada potom, co jsem prejmenoval par souboru. Jenze, kdyz je prejmenuju zpatky na puvodni jmena, tak budou stejne prehazene jako na zacatku a kdyz jim dam jmena jen 01 az 16, tak budou pekne poporade.

[Ash]

Pořadí podle vytvoření beru zpět, to bylo naposledy u FATky, u těchto FS to bude trochu jinak.

Mám hrubou představu o vnitřní struktuře adresářů, ale ne dostatečnou abych to byl schopen pochopit :(

Zkoušel jsem dělat touch a b c z w x y d aa zz bb a podobně a kupodivu i unsorted ls -U to bylo pěkně seřazené :) Asi krátké názvy bez mezer... Nechápu to :)

[Ash]

Vypadá to jako kdyby se pozice souboru v adresáři sice nějak vybírala podle názvu, nebo hasne názvu... ale proč by se to proboha dělalo... :)

[Jooky (inactive)]

viz. man 8 tune2fs

...
dir_index
Use hashed b-trees to speed up lookups in large directories.
...

Dvovod je rychlost, nacitanie 'dir listu' v adresari kde je hoooodne suborov moze celkom dlho trvat.

[Ash]

Pokud kopírujete celý adresář, tak se soubory v něm obsažené kopírují v pořadí, v jakém jsou v tom daném adresáři (zpravidla pořadí v jakém byly vytvořeny). Není tam žádné "výhozí řazení podle názvu souboru", přestože by si to někdo mohl myslet, neb je zvyklý v tomto pořadí soubory vídat.

Otázka zní -- proč potřebujete na cílovém systému mít soubory v adresáři umístěné v nějakém předem daném pořadí? Proč zrovna podle názvu? Většina lidí to totiž nepotřebuje.

[Dalibor Smolík]

Předem dané pořadí může být pořadí uvedené na originálním CD a to asi důležité je.

[Ash]

Na originálním CD to bude předpokládám od track 1 do track N :) a protože názvy začínají track# tak to stačí kdykoliv seřadit podle názvu, čímž se získá kýžené původní pořadí. Dotaz tedy trvá.

[Ash]

Spoléhat se či využívat k něčemu pořadí inodů mi prostě přijde nestandardní požadavek.

[Leshy]

No potrebuju to k jednoduche veci. Tou je, ze data kopiruju na samba server a problemem jsou pak windows programy. Treba winamp (ve kterem to jde jeste nastavit, ale v urcitych verzich to stejne nefunguje) nebo windowsi mplayer prehravac (ve kterem jsem nastaveni nenasel) si pak soubory do playlistu berou podle casu vytvoreni. No a kdyz mi je cp kopiruje ve spatnem poradi, tak se pak i spatne radi windowsim uzivatelum. No a abych se po kazdem zkopirovani dat mel na server jeste prihlasovat a vse touchovat tak to se mi zda moc komplikovany.

[Ash]

Hm, tragédie, jeden by myslel že playlist jde aspoň seřadit :)

Pokud vám vyhovuje řazení podle názvu, tak bych asi použil něco jako find | sort | while read file; do cp "$file" destination; done či podobné řešení (klidně pro celou adresářovou strukturu, v rámci adresářů to bude seřazené a to stačí).

[Leshy]

Hm, tragédie, jeden by myslel že playlist jde aspoň seřadit :)

No to mi povidej, takovej uzivatel ve windows si klikne pravym na slozku beatles, ve ktery jsou vsechny jejich alba, a da zaradit do playlistu. No a to uz jen tak neseradis.
A ted ta horsi stranka, ja si server klidne primountuju, sesortim a zkopiruju to v konzoli, ale co jini uzivatele, kteri si daji, treba v kde, mista v siti a tam to pekne nasypou... a jsem tam, kde jsem byl.

p.s.: ted jsem si vsiml, ze mi vykas, tak promin za tykani
p.p.s.: to co jsem psal vyse, ze s prejmenovanim se to poradi stejne meni - stale me zajima proc

[Leshy]

Ajaj, sorry za ten styl. Uz asi spim.

[Ash]

V pohodě, dobrou... :) Třeba to zítra někdo objasní. Každopádně řešení bych viděl přecejen v tom find sort cp.

[Ash]

Nebo uživatelům rovnou vygeneorvat seřazené playlisty.

[Ash]

http://lkml.org/lkml/2001/6/29/197

... Is there any standard...?

Hans Reiser:

Unix filesystem hierarchies are defined to be a partial ordering, not a full ordering.

bash-2.05# mkdir fu
bash-2.05# cd fu
bash-2.05# touch one two three four
bash-2.05# ls -U
one  two  four	three

Hans

Docela jsem se pobavil :) Alespoň že na těch widlích to je podle času vytvoření, jinak by to bylo neřešitelné.

[Ash]

Na reiserfs to vypadá že záleží na délce (což má logiku protože jde o ukládání názvů a u ukládání dat je důležitější množství než obsah).

bash$ touch d cc bbb
bash$ ls -U
d  cc  bbb
bash$ rm cc
bash$ touch aa
bash$ ls -U
d  aa  bbb  ccc  ddd
bash$ rm ccc
bash$ touch eee
bash$ ls -U
d  aa  bbb  ddd  eee
d  aa  bbb

U stejně dlouhých názvů je asi preference alfabetického pořadí.

U jiných FS je to samozř. jinak.

[Leshy]

Jako vysvetleni mi to staci. Aspon jsem se zase dozvedel neco pro me neveho.

[Peter Lehotsky]

Na XFS ten priklad neplati, poradi je spravne.

[Ash]

Na XFS asi bude potřeba najít jiný protipříklad :)