Keresés

Új hozzászólás Aktív témák

  • tpotyka

    tag

    válasz tpotyka #52551 üzenetére

    Köszönöm, ezennel robocopy csekkolva, szinte élmény. :DD

    A parancssoros robocopy alkalmazásáról:
    - Rendszergazdaként futtattam végül. (Nem rendszergazdaként futtatva nem akart volna mindent másolni, pedig megnézve, a hozzáférések elvileg ott is rendben lévők voltak.)
    - Sebességben kb. köztes: a Win filekezelőnél lassabb kb. 20%-kal, de gyorsabb a Total Commandernél, ezt sasolni menet közben a feladatkezelőben lehetett. (Más mód nem adta magát, itt nincs vizuálisan előbukkanó másoló panel, mint a Win filekezelő vagy a TC esetében. Tehát sajna nem nézegethető, hogy menet közben hol tart, csak HDS-re ránézve.)
    - Registry babrálást szerencsére nem igényel és elég sok minden szofisztikáltan beállítható, mindebből én pluszban az „/E” mellé a „/LOG:”(…) opciót odatűztem még, hogy nyoma legyen, mit művelt – 41 megás lett ez önmagában. Ebből csak a gyors végösszefoglalót néztem, így tudni, hogy 2 file-t kihagyott, 9db-nál failed, de ez a forrás HDD-nek valami System Volume Information nem érdekfeszítő állománya. Azaz a lényegi adatok ez alapján megvannak. A vélhetően indifferens 0,0012GB hiány sokkal jobban elviselhető, mint a 2GB ill. 4000 db saját file kiszórása a filekezelő által.
    - Helyesbítenem kell idevágóan a Windows-t illető kritikus megjegyzéseimet, a mód adott volt, csak nekem nem volt ismeretem erről. A robocopy úgy tűnik, long path állomány másolásra jó áthidaló lehetőség „házon belül”. Bár valóban bonyi annak, aki nem PowerShell user. Például, ha hiddenbe rakja (mint meghökkenésemre nekem), még némi bogarászást és parancssoros utókezelést igényel, hogy látszódjon is az eredmény.
    - Bónusz, hogy az eredeti mappadátumok is megőrződtek, amire a TC sem volt hajlandó.
    - Annyiban lecsekkoltam a Tulajdonságok alapján, hogy a méret és file db szám egy-két eltéréssel stimmel a log kimutatással, a másolt állomány további ellenőrzése még ezután következhet.

    Nagyon köszönöm, BitRider, cigam, Dluinet, efemm, mezis: a segítségeket és a jó ötleteket a megoldásra, van, ami ezáltal került még inkább előtérbe. :R

    Hátha valaki hasznát veszi, háttéranyag efemm korábbi linkje és topikfolyamban felbukkanás mellett:
    Ömlesztett parancs opciók és TeraCopy összevetés
    MS okítóanyag
    Könnyed ismertető és Xcopy összevetés
    Esettörténet és TC, 7zip összevetés.

  • tpotyka

    tag

    válasz Dluinet #52554 üzenetére

    Te meglehet, sokfélék vagyunk, mi, emberek, és érthető is az ilyen koncepció.
    Jómagam semmi IT eszközt használtan nem veszek. A menet közben kipróbálás tárgykörét sem tartom fenn ilyesminek, s eleve a tervszerűségre vagyok ráállva, így is bőséges, ahol biztos alap csakis a Gondviselés. :)

  • tpotyka

    tag

    válasz Dluinet #52552 üzenetére

    Nagyon köszi a buzdítást, bár nem ismerheted itt „a minden gondot”. :)
    Természetesen párhuzamosan a Milyen NAS (...) ? topic olvasása is megy, a napokban ez is nagyobb arányban. A Synology eddig rokonszenvesebb, de még túl sok minden új nekem a témában, bár már azzal is szűkíthető a kör, hogy ha min. 4 lemezes legyen, de amúgy milyen gyártók lemezeit csípőből kizárom. Eddig nem volt sürgető a téma, s a hosszú távra tervezés jegyében kezelendő, de épp ezért értelmesen kell a választást és beszerzést lezongorázni.

  • tpotyka

    tag

    válasz Dluinet #52550 üzenetére

    efemm: persze, majdnem helytálló a célzás :B és már-már esélyt adnék mégis a Robocopy-nak. Zavar is az eltelő idő, történetesen fejben már az egyenleg villog, hogy hány munkaóravesztegetés folyik itt forintosítva vs pl. most azonnal, de megfontoltan beruházni egy NAS beszerzésbe, ami előbb-utóbb úgyis kell. A szakaszos másolás, mint említettem nem lenne alkalmazható, a mapparendszer struktúrája miatt. A gép SSD-je köztes állomásként nem elég tágas a művelethez, a külső SSD-m - belegondolva a vetületekbe - csak arrébb tolná a problémát. Mivel a napokban mozgásban voltam, maradt a tájékozódás. Az egy dolog, hogy 100+ km-es utak ide-oda és a sokórás munkavégzéses állomások között laptoppal mennyiben tud előkészülni az ember, de garantáltan nem ideális az épp érzékeny HDD-k eközbeni cimbászására. Nem kifejezett cél a további adrenalin-szint növelés. :D

    Dluinet: szerintem téged is érdekelne, miként fut le, pl. hogy ilyen előzmény után legalább ismert legyen a hibafolyamat, ha jelentkezik. :) Az idő pedig onnantól számít, hogy a másolást (majdan) végző gép időnként intenzív mozgásban van, velem együtt, ld. fentebb. Aktuálisan azért tud előkerülni a cselekvés, mert talán a köv. 48 órában nyugton marad a gép (velem együtt) és hozzá a HDD-k is, ha muszáj. S előbb még a foghíjas felmásolások 1,8TB anyagát kell megfelelően letisztítani.

  • tpotyka

    tag

    válasz efemm #52547 üzenetére

    Köszi, efemm. Mókás, épp az imént olvastam a Robocopy-ról.
    Nyakig ülök az eddigi és azóta talált tematikus cikkekben, illetve a kapcsolódó visszajelzésekben. Eddig mindnél van valami bibi vagy kockázati tényező. A Robocopy-ra panasz volt, hogy lassú. A Long Path Fixer testvér prg-ja levakarhatatlan, így LPF-fel se tudok jószívvel próbálkozni. TeraCopy preferálja a szakaszos másolást, de az nekem nem pálya. Van az Xcopy, amire már nem emlékszem, mi volt panasz.

    A korábban említett Powershell-es javaslatra is vegyes véleményezést olvastam, nem mindenkinek működött. Úgy sejtem, onnantól, hogy nem gépen belüli C a játéktér, a Windows megpecsételi a szerencsétlen korlátozásával a lehetőségeket.
    S tipikus problémahalmozás, hogy külső HDD a szereplő, akár nemcsak cél, hanem forrás is.
    A Win-ben long path engedélyezés meg elég értelmetlen lehetőség, mert hiába engedi a létezést, ha kezelni márpedig nem engedi. Ráadásul a registry babrálásnak különféle rendszerlékelő hatására is felhívják a figyelmet.
    Keresem a szavakat erre az idióta helyzetre.

    Mivel alapból min. 4-6 órát tesz ki ez a másolás, abszolút nem mindegy, milyen lyukra futva próbálkozom, esetleg úgy, hogy az utsó 1 percben derül ki, hogy ez vagy az hibádzik, vagy ki sem derül. Közben az eredeti tök tiszta friss HDD-t nyüstölni másoláspróba-törlés-újramásolás körökkel. :(
    Nem akarom elhinni, hogy külső szerverre vagy Windows-on kívüli op-rsz-re (pl. a többek által említett Live Linux-ra) kellene kimászni csak azért, hogy a Win végrehajtson valamit, amit amúgy lazán tudna, és felhasználóként mégcsak lehetőséget sem ad, hogy rsz-en belül elvégezhető legyen, egy olyan "kompatibilitás" ürügyén, amire egyáltalán nem volt felhasználói igényem. De azt hajítja hozzám alapértelmezett kényszerpályaként.
    Szürreális, hogy differenciált mapparendszereket, amiket éppen érdemes és szükséges backup-olni, Win alól durván megnehezítik. :(((

  • tpotyka

    tag

    válasz mezis #52545 üzenetére

    Ha arra utalsz, hogy átírni a problémás file neveket ill. mappákat: adva nyilván a lehetőség, de ahogy jeleztem korábban, szerte széjjel a cirka 4000 db túl sok megkeresni és átírni, ez embertelen. S végül is a számítógépeket mára éppen már feltalálták, adjunk hát kibontakozási teret, ne vegyük el a gépek munkáját. :)

    Az mondjuk még tesztelhető, hogy a 95%-ot kitevő nagy belső adatmagot külön rámolni, ami igazoltan mozdítható, és ezt utólag beburkolni az újfent létrehozandó, utálatos plusz-hosszító mappákba, és aztán egyéb mellérendelt mappákat külön betenni. Amennyiben meghajtón belül engedni fogja már pl. a Total Commander úgymond belül az elérési út növekedést. Ugyanis laptopon belüli meghajtón belül figyelmeztetéssel ugyan, de a TC végrehajtotta a túl hosszú másolást is, csakhogy két külső között nem, bár Windows filekezelőhöz képest azért fele mennyiségnél lázadt. Időben persze ez az említett TC próbakör így is 6 órát tenne ki, általam nem ismert kimenetellel, plusz utórendezés, hozzá a nem kizárható emberi hibaszázalék. Összvissz pepecselős ez is picit.

    Önmagában jó hír, hogy több út eredményre vezethet, a kérdés, hogy melyik lehet a legkevésbé strapás – számomra. Nem edzettem magam a gondolatra, hogy egy „egyszerű” adatmásolás miatt Linux-szal kavarjak.

  • tpotyka

    tag

    válasz cigam #52543 üzenetére

    Sajna nincs NAS „a közelben”. :N Úgy veszem, egy plusz príma okot mondtál, hogy legyen…
    Olyan infrastruktúra van, amit saját cégesen finanszíroztam, és NAS „közelbe” cserkészésére nem került sor, még.
    Jóllehet ezt a másolást hamarabb kellene azért lebonyolítanom, lehetőleg a jelenlegi eszközpark szükségtelen gyepálása nélkül.

  • tpotyka

    tag

    válasz cigam #52540 üzenetére

    Köszönöm, a helyzet, hogy nem szoktam telepítgetni új op.rsz-eket, pláne Linux-ot nem. :B Szerencsés volna enélkül megoldani, vagyis a megoldási sorban kb. a Linux bevetés várakozna a végén. Hasznosak a háttérinfóid, az ilyen korlátozások csak addig nem bosszantóak, amíg nem érintik az embert. Megnézem ezt a Win11-es linket.

    Amúgy egyáltalán nem állandó jelleggel adódik ilyen másolás, ebben az eredeti mapparendszerben is csak azért lettek hosszabb elérési utak, mert rajtam kívül álló személyek mappahierarchiában fölé pakoltak kevés, rövid neves mappát, de ez épp elég volt, hogy a korábban gond nélkül mozdítható állományban úgy 4000 db file problémássá váljon.

    Még az jutott eszembe, hogy a rar tömörítgetéssel tehetnék egy próbát, nem a laptopra, de van egy erre átmenetileg bevethető külső 2TB-os SSD-m (forrás HDD-ról SSD-re rarosítani, onnan cél HDD-re kicsomagolni – ha hajlandó). Bár időben biztos hosszas művelet lenne, de legalább a mappa dátumok is maradhatnának eredetiek. Ez az SSD éppen exFAT maradt (nem formáztam NTFS-re), ez is érdekes lenne, milyen nyúzást enged meg, dromedár rar rápakolás ürügyén.

    „Ha nincs más a céllemezen, egy klónozó programmal szektorról szektorra átmásolod a lemezképet egyikről a másikra.”
    Sajnos abszolút nem ilyen egyszerű. Archív és biztonsági másolat a téma, de a céllemezre más is kerül. Persze a sorrendet alakíthatnám, azaz lehetne ez a problémás 800GB+ anyag az első rákerülő pakk a cél HDD-n, de az emiatt klónozás stb. szintén elég körülményes, s a forrás HDD formáját ennyire nem nyomatnám rá a cél HDD-re, ami a klónozással adná magát.

  • tpotyka

    tag

    efemm, köszi, nem tudom jó-e. :) Soha nem próbáltam, és két kézen számolom szerintem, amit Powershell színtéren volt szükséges intéznem, nem ilyen parancssoros közegben vagyok otthonos. Látom, a linkelt anyagban elég sok példa van, végigfutom.
    Ha nem problémázna a külsőről-külsőre másolással, ami összességében nagy, de 1 TB-ot el nem érő és hosszú elérési utas, akkor az a gyanús, hogy miért nem terjedt el ez az intézési mód az ilyenféle a szituációra.

  • tpotyka

    tag

    válasz BitRider #52537 üzenetére

    Szia, köszönöm a felvetéseidet. Win 11-es a laptop. AMit linkeltél - csak a Win 10 esetében állítható be hosszabb elérési út? Éppen van Win10-es laptopom is, de a másolási sebesség vélhetően drasztikusan beesne annál.
    Ahogy a hivatkozott előzményemben jeleztem, nagyon sok file és sok mappa van, az átnevezés kb. no way.
    Linux nincs egyik gépen sem, de meggondolom. Abból nem adódhat gond (pl. bármi szintű adatvesztés), hogy Linux végzi (akárhogyan is) a másolást, és aztán alapvetően Windows kezelné az állományokat?
    A TeraCopy témában utána olvasok. Ezt használtad már? Rendben megvan minden egy másolás után? ;)

  • tpotyka

    tag

    Sziasztok, olyan programra volna szükség, amely hosszú elérési úttal képes sok file-t, nagy állományt másolni, éspedig külső adattárolóról másik külső adattárolóra. Sajnos a Total Commanderrel sem volt ez végezhető. A nagy összméret miatt pedig a zip vagy rar tömörítéssel kicselezés nem járható út.

    Olvastam egy Long Path Fixer nevű lehetőségről. Ismeri, használta ezt valaki? Mivel lényeges az állományok teljes megléte a célhelyen, érdekel az is, ha van erről esetleges tapasztalat, még továbblépés előtt.

Új hozzászólás Aktív témák

Hirdetés