Windows Explorer esete 1000+ fájllal

Véletlenül létrehoztam egy nagy rakás fájlt, amit ki akartam törölni. Kijelöltem a fájlokat, majd nyomtam egy shift+deletet. Erre a rendszer megkérdezte, hogy biztosan a lomtárba akarom-e helyezni a fájlokat. Azt hittem, lemaradt a shift, ezért újra megpróbáltam, de megint ezt kérdezte. Elkezdtem módosítani a kijelölés méretét, és kiderült, hogy 1024 fájlig azt kérdezi, törlöm-e a fájlokat, 1024 felett a lomtárba helyezésre kérdez rá.

De a történetnek itt nincs vége. Újra kijelöltem az összes törlendő fájlt, nyomtam egy shift+delete-t, majd elfogadtam a lomtárba helyezést. Azonban a művelet befejezése után a lomtárat üresen találtam. A kíváncsiságom nem hagyott nyugodni, létrehoztam 1025 fájlt, kísérletezni. Végül kiderült, hogy 1000 fájlig a lomtárba helyezés valóban a lomtárba való áthelyezést jelent, 1001 fájltól törlést.

Os: Windows 7 x64

Aki ki akarja próbálni, generálhat 1025 fájlt ezzel a powershell commanddal: 

for ( $i=0; $i -le 1024; $i++ ) { echo $null > file.$i; }

Vagy ha nincs powershellje: http://batserver.freeweb7.com/index.php/files/others/1025_file.zip

( GoRien | 2010. 01. 21., cs – 00:26 )

Ezzel egy sort én is fogok szórakozni. :)
===================================================
Ubuntu 8.04.3, AIX, Windows XP Home, Windows XP Pro

( doc | 2010. 01. 21., cs – 08:48 )

beszaras :D
kar hogy nincs windowsom kiprobalni...

( sh4d0w808 | 2010. 01. 21., cs – 09:41 )

Gyönyörű, a trehány programozás megint felütötte a fejét...

-------------------------
Trust is a weakness...

( log69 | 2010. 01. 21., cs – 10:37 )

jah, ilyen már régóta van. pl. a registry-ben beállított fájl típus-hoz rendelt menüpont a jobb gombos lokális menüben csak 15 vagy kevesebb kijelöléshez jelenik meg, 16-tól felfelé már nem :D

tehát, ha pl. a registry-be beállítod az alábbi 2 bejegyzést (név + parancs) a .jpg kiterjesztésű fájlokhoz:

HKCU -> "SystemFileAssociations\.jpg\shell\Command"; ValueType: string; ValueName: ""; ValueData: "MENÜPONT NEVE"

HKCU -> "SystemFileAssociations\.jpg\shell\Command\Command"; ValueType: string; ValueName: ""; ValueData: "PROGI.EXE"

akkor ez a menüpont csak 1-15 db kijelölésig jelenik meg jobb egérgombra :)

szerk.: azt már nem is említettem meg, hogy a lefuttatás egyszerre!! történik meg, tehát nem sorban :DDD

(XP és Vista alatt tesztelve)

( zaphodb v | 2010. 01. 21., cs – 10:50 )

32bites xp alatt 1025 fájlra shift del, nem a lomtár jön be.

na ezt visszavonom, hálózatos meghajtón nyomja így, localban megy pikk-pakk:
"viszont a sima del nem gyenge: percekig csinálja a prepare to delete és pörgeti 100on a procit, aztán 18 percet ír ki a törlésre. mondjuk eleve a fájlok létrehozása is sok időt igényelt, kb 1-2 perc. és ezek 0 KB méretű fájlok :-P

szerk: ja tudom, hardvert venni tudni kell ;)"

ui.: ettől függetlenül tessék egy scriptes oldal.

Gyanítom, hogy az ntfs driver sokat javult xp óta, elsősorban ez lehet az oka annak, hogy nálam a létrehozás, törlés 1-2 mp-et vesz csak igénybe.

A scriptes linket köszönöm, bár remélem nem azért kaptam, mert a fenti 1 sor hibás. :) Egyébként history alapján már jártam az oldalon. :)

na most :P 66667 fájl törlése, del gomb, kukába, nem nagy dolog, fél órák kérdése, de megcsinálja. nyitva van a kuka is, nézem alul a státusz sort, azt írja 65899. há mondom van ilyen, f5. erre 65899-től visszaszámol 0-ig, kis homokóra, zseblámpa, fixen homokóra (zseblámpa megáll) míg 0-tól elszámol 65899-ig. pedig a fájlok ott vannak mind, legalábbis a legutolsó 66666-os névre hallgat.

hiába, a számokkal bánni nem egyszerű.

C:\RECYCLER\S-1-5-21-507921405-926492609-725345543-443139-ben dir is 65899-et számol.

megszámoltatva is (maradék sorok a dir egyéb üzenetei):
C:\RECYCLER\S-1-5-21-507921405-926492609-725345543-443139>dir | wc -l
65906

nemcsak az explorernek vannak gondjai a számokkal:
C:\RECYCLER\S-1-5-21-507921405-926492609-725345543-443139>ls -l | wc -l
32766

ui.: meglepetés, a kukában a ctrl+a, majd jobb gomb megy azonnal.

sok fájl az sok, máshol is: 


TEST$ a=0 ; time while [[ a -le 66666 ]] ; do touch $a ; let a=a+1 ; done

real    9m2.49s
user    0m50.41s
sys     2m22.84s

TEST$ time ls -1 | wc -l
66667

real    0m5.49s
user    0m0.27s
sys     0m1.63s

kis aranyos érdekesség:
TEST$ time ls -1tr | tail
66627
66620
66665
66664
66663
66662
66661
66660
66659
66666

real    0m17.37s
user    0m0.20s
sys     0m3.08s

TEST$ time rm *

real    2m11.07s
user    0m0.36s
sys     0m5.98s

mondjuk azt tegyük hozzá, hogy itt a ~-om másik gépről kerül csatolásra nfsv3-on.

Az új Ubuntu :)
$ a=0 ; time while [[ a -le 66666 ]] ; do touch $a ; let a=a+1 ; done
real 3m27.681s
user 1m30.086s
sys 2m2.268s

$ time ls -1 | wc -l
real 0m0.359s
user 0m0.292s
sys 0m0.076s

$ time ls -1tr | tail
real 0m0.436s
user 0m0.216s
sys 0m0.228s

$ time rm *
real 0m2.259s
user 0m0.644s
sys 0m1.612s

Btw szutyok P4HT-s gép, öreg ide-s hdd-vel.

ez maz otthoni gép, 9.10-el: 


~/TEST$ a=0 ; time while [[ a -le 66666 ]] ; do : > $a ; let a=a+1 ; done

real	0m2.973s
user	0m1.420s
sys	0m1.450s
~/TEST$ time rm *

real	0m1.203s
user	0m0.400s
sys	0m0.740s

/dev/shm/TEST$ a=0 ; time while [[ a -le 66666 ]] ; do : > $a ; let a=a+1 ; done

real	0m1.541s
user	0m1.310s
sys	0m0.230s
/dev/shm/TEST$ time rm *

real	0m0.594s
user	0m0.240s
sys	0m0.360s


hron@sunshine /tmp/TEST$ time for x in $(seq 1 66666); do : > $x; done

real	0m2.688s
user	0m1.124s
sys	0m1.550s
hron@sunshine /tmp/TEST$ time rm *

real	0m2.925s
user	0m0.272s
sys	0m2.652s
hron@sunshine /tmp/TEST$

Gyorsabb fajlletrehozashoz lassabb torles tarsul - ReiserFS, C2D 2.4G proci.
-- 


()=() Ki oda vagyik,
('Y') hol szall a galamb
C . C elszalasztja a
()_() kincset itt alant.


TEST$ a=0 ; time while [[ a -le 66666 ]] ; do touch $a ; let a=a+1 ; done

Nagyon igyekeztel, ennek ellenere sikerult tobb mint 64K-nyi processzt krealni. Igy persze hogy lassu :-) Hagyd ki a touch-ot, kategoriakkal gyorsabb lesz. 


TEST$ a=0 ; time while [[ a -le 66666 ]] ; do : > $a ; let a=a+1 ; done

(Mivel a while a [[ a : (masneven true) es a let is shell belso parancs, ez egy db processzt fog jelenteni az eredeti hatvanakarhanyezerjevel szemben.)

hát én már csak ilyen kutyaütő scriptelő vagyok :)

de tényleg gyorsabb (~ másik gépen): 


TEST$ a=0 ; time while [[ a -le 66666 ]] ; do : > $a ; let a=a+1 ; done

real    5m6.79s
user    0m1.22s
sys     0m6.75s

/tmp/TEST$ a=0 ; time while [[ a -le 66666 ]] ; do : > $a ; let a=a+1 ; done

real    0m45.54s
user    0m1.22s
sys     0m39.25s

Ez utóbbi meg lokálisan.

ui.: volt róla szó tavaly, h mennénk hozzád tanulni, de nem sikerült beütemezni.

well, az explorer.exe szereplése is elég béna, de ott legalább közben egy másik explorer ablakot lehetett használni. viszont nautilus keményen letérdel.

szerk: fel is raktam gyorsan egy dolphint. ez egész jó, kicsit beszürkült, de fél percen belül magához tért. míg a nautilus azóta sem áll a helyzet magaslatán.

szerk2: konqueror szintén jó, felugrik 45% kb 30e fájl, megszürkül, aztán kisvártatva ott a 66ezer. nautilus közben már mutatja hány fájl van, de még mindig folyamatosan szürke.

"az ntfs driver sokat javult xp óta"

az NTFS kódja csak lassulhatott mert Vista óta van Tranzakcionális NTFS, ami plussz overheadet rak rá. Persze máshol meg optimalizáltak rajta. De ez annyira nem baj/észrevehető ha normális 2 magos professzorod van, akkor inkább az előnyei jönnek elő (nem pont ennek, hanem úgy általánosságban a fejlettebb algoritmusoknak).

( strangelove | 2010. 01. 21., cs – 12:29 )

kicsit off:

W2K óta:

FOR /L %G IN (1,1,1025) DO @TYPE NUL > TMP%G.TMP

barátod: FOR/?, illetve batch fájlban ne feledkezz el arról, hogy a FOR ciklusváltozót két százalékjellel kezdjük!

powershell = TrBS ( tracktorrider blinding system ) vagy spanishvax (jajj ne, jön gabucino, rumi és NEUROFIRE :)

http://nocirc.org/

Batch builtin commandok szintaxisát soha nem tudtam megjegyezni, ráadásul elég távol esik a legtöbb programozási/scriptnyelvben megszokott szintaxistól. Powershell meg kéznél van, és az egyáltalán nem érdekel, hogy melyik része melyik korábbi programozási/scriptnyelvből van átemelve.

( kalamajka | 2010. 01. 21., cs – 12:34 )

hint: 1-2 masodpercig tartsd nyomva a shift-et es utana a delete, igy mukodik (tobb fajl eseteben megtovabb kell nyomvatartani). Vitatando, hogy ez bug vagy feature... :-)
---
"A legjobb dolgok az életben nem dolgok."

( bri | 2010. 01. 21., cs – 12:52 )

most nem is azért, de ki az, aki egyszerre ezernél több fájlal akar bármilyen műveletet végezni? azért ilyen volumenű (főleg, hogy csupa üres fájl!) műveletvégzésre nincsenek még kiképezve a mai számítógépek... :p

u.i.: ha az ezeriksz fájt tartalmazó mappát egyben törlöd, fogadunk, hogy sikerül?

De ezt a hasonlatot tuti nem buktam be... Egy amatornel azert nem biztos, hogy felgyulik annyi, mert az allandoan nezegeti a kepeket, hogy mi sikerult, mi nem, ami nem, az kuka. Egy profinal nagyon keves a hibaszazalek.
-- 


()=() Ki oda vagyik,
('Y') hol szall a galamb
C . C elszalasztja a
()_() kincset itt alant.

( zaphodb v | 2010. 01. 21., cs – 20:36 )

nálam nem így viselkedik. win7, 64bit.
- shift+del, rendesen letöröl 1025 elemet is,
- viszont 1000-nél több elemet sima del-el nem teszi a lomtárba (azért ez se egy enterspájz limit).

sem törlésnél, sem mozgatásnál semmiféle (különösebb) teljesítmény problémája nincsen (gyorsabb mind dolphin). leszögezhetjük, hogy van fejlődés az xp-hez képest (nem hiszem, hogy a vasak különbözősége ennyit számítana).

( sixtyhz | 2010. 01. 22., p – 12:28 )

Are you sure you want to permanently delete the 1,025 selected items?