Listovani slozek pri operaci

[Jan Rysavy]

Ano, přesně takovou operaci jsem měl na mysli - dám kopírovat celý delší strom s větším objemem dat a občas ještě kontroluji a případně měním (typicky třeba datum z exif) souborů co se kopírují až na konci.

Pokud po nakopírování zdrojové soubory smažete, jsou Vaše obavy o ztrátu dat skutečně na místě
V opačném případě pouze riskujete, že zdroj a cíl nebudou po operaci shodné.

Mimochodem, navrhované řešení

Takže pokud už dělat nějaké úpravy, tak v tom smyslu, aby se zkopírovaly i soubory nově vytvořené po začátku delšího kopírování - nebo na takové soubory upozornit obdobně, jako upozorňujete na soubory které byly smazány/přejmenovány po začátku kopírování. Tedy "listovat" (také/jenom) v době kopírování.

by nebylo reálné z jednoho důvodu. Představte si jeho nejvíce paranoickou verzi, ve které bychom celý strom nakopírovali a na závěr jej ještě porovnali (třeba i podle obsahu). Tato operace nebude atomická, uživatel bude stále mít možnost během jejího průběhu změnit již zkontrolované soubory. Ve chvíli, kdybychom na závěr porovnání dospěli k závěru, že jsou stromy shodné, už by to nemusela být pravda.

Závěr: se soubory to chce opatrně

[Datalog]

Tato operace nebude atomická, uživatel bude stále mít možnost během jejího průběhu změnit již zkontrolované soubory.

Souhlasím, že ideálního stavu nelze dosáhnout. Akorát si musím dávat pozor a i když se kopíruje delší, třeba 1/4 hodinový, blok souborů tak nad ním raději nepracovat. Nesmím se (jako doteď, chybně) spoléhat na podívání na bar že "ty moje" soubory přijdou na řadu odhadem až za 10 minut. Nebo si kopírování rozdělit na menší bloky.

Nekteri s tim spokojeni nejsou. Uz jsme 2.

IMHO nám dvěma nevyhovuje každému něco jiné. Jednomu doba čekání na sestavení stromu (a při tom zablokovaný Salamander) a druhému sestavení stromu jako takové.

Je nás málo, kdo pod windows pracují s velkým nestovaným stromem s mnoha malými soubory. To se pod MS nenosí.

A vzhledem k faktu, že jsem (jsme?) také vývojáři, tak chápu, že pro můj případ není dobré měnit logiku která doteď fungovala a na kterou si ostatní zvykli (ostatně jak jinak předem zjistit celkovou délku kopírovaných dat). A případné rozšíření (další kontrola při běhu kopie) by zase kopírování zpomalila a stejně dořešila jen částečně.

[cincura.net]

Je nás málo, kdo pod windows pracují s velkým nestovaným stromem s mnoha malými soubory. To se pod MS nenosí.

A vzhledem k faktu, že jsem (jsme?) také vývojáři, tak chápu, že pro můj případ není dobré měnit logiku která doteď fungovala a na kterou si ostatní zvykli (ostatně jak jinak předem zjistit celkovou délku kopírovaných dat). A případné rozšíření (další kontrola při běhu kopie) by zase kopírování zpomalila a stejně dořešila jen částečně.

Kdyz kopiruju celej strom zdrojaku (kolem 2GB) tak to je mazec. Tam jsou i soubory kolem 1kB.

[Ether]

Mimo Salamandera, částečným řešením by mohl být mountovaný filesystém v souboru. Narozdíl od archivů je práce s ním na stejné úrovni jako s normálním oddílem a v případě, že je potřeba celý strom zkopírovat/přesunout, stačí odmountovat a pracuje se s jedním souborem. Navíc se správnými nástroji nemusí být velikost takového oddílu neměnitelná.

[Ether]

Před nedávnem jsem se dostal k notebooku s Vistou a zděsil jsem se, když jsem zjistil, že Explorer při kopírování prochází daný adresářový strom naživo (tedy ne předem, jako Salamander).

Když jsem operaci kopírování započal, objevilo se okýnko s progressbarem a zbývajícím časem operace (a také celkovou velikostí kopírovaných souborů). Ovšem v době, kdy už operace měla být dávno hotová podle toho prvního odhadu, jsem si všiml, že celková velikost se už několikanásobně navýšila a chvílemi ještě stoupá, stejně tak se zmenšovala vyplněná část progressbaru a prodlužoval očekávaný čas.

Z mého pohledu je to přinejmenším nepřínosné až kontraproduktivní a navíc značně matoucí. Nechápu, jak si může někdo myslet, že progressbar je adekvátní indikací průběhu operace, kde není předem známo její trvání nebo náročnost.