Mij lijkt het een bug maar ik vond niet waar ik zoiets zou moeten rapporteren
.
[/quote]
- Je gebruikt wel /E (ipv /S) ? Bij een move van een lege map (waar dus helemaal niets in staat) wordt wel de datum meegenomen.
[/quote]
Ik gebruik /E ja, en nee die pakt niet (alle?) de datum mee dan. Of hij pakt hem misschien wel mee, maar verknalt het dan weer door hem opnieuw te wijzigen of zo, dat lijkt mij de meest waarschijnlijke gang van zaken maar resultaat is hetzelfde. Kan zijn dat gewijzigd of gemaakt wel juist was, maar minstens 1 van de 3 tijd-stampers(
) zat mis.
- Die Compressie blijkt inderdaad niet mee te worden genomen (encryptie niet getest).
Compressie lijkt te omzeilen door er 2 opdrachten van te maken. bijvoorbeeld:
robocopy %SRC%\ %DEST%\ /W:0 /R:0 /MOVE /E /FFT /DST /DCOPY:T /copyall /IA:C /A+:C
robocopy %SRC%\ %DEST%\ /W:0 /R:0 /MOVE /E /FFT /DST /DCOPY:T /copyall /XA:C
Met /IA:C worden alleen gecomprimeerde bestanden geselecteerd, waarbij met /A+:C de compressie wordt aangezet. De andere opdracht verplaatst dan de rest van de bestanden.
Aha, slim gezien, dankuwel!
- Mappen als "System volume information" en "Recycler" sluit ik meestal uit, ik ben er nog nooit tegenaangelopen dat het account waaronder Robocopy draaide gedocumenteerd ergens geen leesrechten had (wel onterecht, maar was dan een kwestie van rechten corrigeren). Die /b en /z opties heb ik nog nooit gebruikt.
Gedocumenteerd? Je bedoelt dat het de "bedoeling" was dat hij geen rechten had?
Ik heb het gewoon onder de standaard gebruiker uitgevoerd en had per ongeluk een verkeerd pad opgegeven naar system volume information map, namelijk een andere drive letter. En dat merkte ik doordat ik met mijn oren vaststelde dat er niks meer gebeurde en dan met performantie grafieken van Windows zelf heb gecontroleerde dat er geen IO meer gebeurde, en dan met filemon even gekeken welke files hij mee bezig was wannnnt hij schreef ook niet naar de console uit. En toen ik eenmaal zag wat er gaande was heb ik ook in de log gekeken die niet gelocked was gelukkig en gezien wat de fout was. Toen heb ik geprobeerd van hem dan maar vlug rechten te geven op sysvolinf, maar dat helpt dus niet.
Klopt het dat een proces in uitvoering geen andere rechten kan krijgen? Dus als een programma herhaaldelijk hetzelfde bestand probeert te openen, en ik pas de rechten op dat bestand aan zodat hij leesrecht heeft, het proces die leesrechten dan niet krijgt totdat je het herstart? Want dat lijkt mij heel raar, maar zo leek het zich toch te gedragen...
In ieder geval, 30seconden maal 10 pogingen, 300 seconden per bestand, en dat voor een map met duizend bestanden in, dan ben je een pak uren kwijt aan niks. En het gekke was, de map waar dat gebeurde had ik zelf
leesrechten, maar geen schrijfrechten, dus ik weet niet wat het probleem daar precies was, maar zelfs nadat ik lees & schrijfrechten had gegeven deed hij
niet verder. Ik heb hem toen moeten ctrl-c killen en dat doe ik liever niet. Wat ik wil zeggen is, het standaard gedrag van retry tot oneindig kan vervelende gevolgen hebben, en retry tot 10 en 30 seconden is ook al gigantisch lang.
Ik weet niet welk besturingssysteem je gebruikt, in Vista/2008 zijn ook nieuwere versie's van Robocopy te vinden, maar die geven geen duidelijk versienummer weer.
Het is op een XP Pro 32 bit dat ik dat bezig ben/was. En volgens
wikipedia is de versie die je download met de GUI van het
Microsoft Technet artikel de versie die ook bij Vista zit. In XP zit er standaard geen. En eigenlijk, ik ben geen enkele andere officiële bron tegengekomen dan dat technet artikel... ik vind het vreemd dat er geen knowledgebase artikel over bestaat of zoiets zoals voor pakweg .NET versies of de XP Powertools (tweakUI enzo).
Het is dus de op één na meest recente versie, de enige die is gebundeld met de Robocopy GUI momenteel, en de eerste versie die dcopy:T ondersteund.
"Ja, maar..." die zeggen niet veel, bij mij staat daar "5.1.1.1010" als Bestandsversie en hoe juist dat ook zal zijn, daar had ik niks mee geweten vermits ik op zoek was naar versie XP026, vermits dat die met /Dcopy:T was. Nu bleek dat toevallig de versie te zijn die ik al had, maar dat kon ik daar niet aan zien. Hij zegt 't gelukkig wel als je het zo runt zonder argumenten of met
/? :
-------------------------------------------------------------------------------
ROBOCOPY :: Robust File Copy for Windows :: Version XP026
-------------------------------------------------------------------------------
Die RobocopyGUI (de oude) is trouwens gebouwd tegen ik meen een XP versie van Robocopy meen ik, dat je daar geen later toegevoegde opties in aantreft is dan wel verklaarbaar.
Inderdaad, alleen vervelend dat ze wel de meegeleverde versie updaten maar dus niet de GUI die er bij hoort. Enthousiaste programmeurs zoals de maker van die GUI zijn waarschijnlijk zeldzaam en met korte aandachtsspannes
.
En sinds Vista heb je ook /EFSRAW om je EFS encrypted bestanden mee te nemen.
Dat heb ik gelezen ja, maar het idee daarachter lijkt me niet zozeer dat je de bestanden als "encrypted" overneemt, alleen dat je bestanden ruw kopieert zonder ze eerst te decrypten en dan te encrypten. En naar ik mij herinner is die encryptie gekoppeld aan je systeem, waarschijnlijk aan je gebruikersaccount, dus erg handig is dat niet als je naar een andere machine kopieert voor backup toestanden, want gebruikersaccount weg=bestanden waardeloos. Nu goed, voor andere doeleinden is dat dus net wel wat je wilt. In ieder geval is het nuttig voor backups van bestanden die je niet kan kan decomprimeren omdat je niet de juiste credentials hebt.
Windows 7 heeft weer /MT voor multithreaded copies.
Hoe kan dat eigenlijk helpen? lijkt mij dat je dan vooral je seektimes de hoogte in gaat jagen omdat hij op 2 verschillende bestanden tegelijk bezig is...processor is toch totaal niet de bottleneck?
Let ook even op dat mocht je je systeempartitie ooit eens willen kopieren dat je dan /XJ meegeeft (exclude Junctions) - dan krijg je tenminste geen recursing fouten doordat elke keer de symlink van AppData naar C:\documents and Settings\XXX\ApplicationData wordt benaderd.
Interessante tip, maar eigenlijk zou ik voor een echte backup graag wel hebben dat hij de soft & hardlinks kopieert
als soft en hard links. Immers anders weet je niet eens meer waar al die links stonden... als je de doelen niet mee kopieert kan dat vervelend worden maar liever een link die ik moet fixen dan eentje die helemaal weg is en waar ik niks meer van weet... en nog liever eentje die naar de backup is aangepast... bestaat daar iets voor al? Symlinks zijn zo superkrachtig maar onder windows een ramp naar mijn gevoel... en onder linux lastig te beheren nog altijd...
Sowieso, een backup van een bootable HD lijkt me onmogelijk met robocopy? Dat gaat toch nooit bootable zijn? Of... ik meen me te herinneren dat de eerste 512kb of 512 bytes van een partitie de bootinfo zijn, dus als je die met iets anders kopieert, of eventueel met fixMBR terug aanmaakt vanuit het niets, werkt dat dan wel? Ik vraag me af of het niet van belang is dat bepaalde boot bestanden op bepaalde sectoren moeten staan dan, vermits dat bootproces toch filesystem onafhankelijk is...
De opdracht die ik gebruik momenteel is iets als :
robocopy "X:" "Y:\Xdrive" /dcopy:T /E /COPYALL /V /LOG:"V:\X partitie - Robocopy log - Xdrive.Txt" /R:1 /W:3 /ETA /FP /TS /tee /XD "X:\System Volume Information"
Met varianten naargelang het vooral om grote of kleine bestanden gaat (namelijk /np komt er bij bij kleine bestanden en /Tee gaat weg, want anders vertraagt de console het proces teveel en staat er een hoop cijfergespam in de log voor niks).
offtopic:
Voor mensen die nu in robocopy zouden zijn geïnteresseerd maar niet weten waar beginnen :
robocopy is voldoende omdat de installer (die van de GUI bij mij toch) heeft gezorgd dat het overal beschikbaar is (al vind ik het niet terug in de path variabele, hoe kan dat eigenlijk want de exe staat onder progfiles\robocopy :x?).
"X:" is omdat ik de hele drive met alles er in kopieer, X:\ kan je niet opgeven! Hij gaat die \ dan namelijk interpreteren als escape van de " er achter en dan gaat alles de mist in... vrij vervelend vermits in padnamen natuurlijk geen " mag voorkomen sowieso en je nu dus zeker moet zijn dat voor je console, X: op \ staat en niet in een submap zit!
"Y:\Xdrive" zorgt ervoor dat er op Y een nieuwe map wordt aangemaakt, of een bestaand herbruikt. Als hij al bestaat behoudt hij zijn datum, anders krijgt hij die van X:, en vermits die er geen heeft als root (denk ik toch niet) krijgt hij die van de kopieer opdracht. In ieder geval, alles van X: wat hij kan vinden komt in deze submap terecht en nergens anders.
/dcopy:T de hele point van deze thread, bewaar de mapdatums. Werkt prima, uitgezonderd enkele haperingen als je /mov(e) zou gebruiken, wat ik niet doe.
/E submappen kopiëren en ook lege mappen meenemen (wie neemt er nu geen lege mappen mee? heb je die zo vaak per ongeluk dan dat het standaard , vermits S voor submappen logischer is, niet gedaan wordt?)
/COPYALL neemt alle properties over, alle wil zeggen alle security eigenschappen zou hij moeten overnemen evenals tijd, wat hij zeker doet, en ik archive bit en hidden en system flags normaal gezien ook.
/V verbose zou meer moeten uitschrijven naar log/console. Nooit zonder geprobeerd.
/LOG+:"V:\X partitie - Robocopy log - Xdrive.Txt" schrijft weg naar tekstbestand dus, ik neem telkens een unieke naam en toch log+ voor het geval ik per ongeluk een bestaande log heb gepakt, dan is de oude tenminste niet weg.
/R:1 /W:3 dus drie seconden wachten en één keer opnieuw proberen, zodat je per file die niet lukt maar 3 seconden extra verlies maakt en de tijd van 1 poging, onmiddelijk meestal.
/ETA toont de verwachte tijd dat hij klaar gaat zijn, voor het eerste bestand is dit doorgaans vele uren ernaast
maar naarmate hij langer bezig is worden zijn voorspellingen nauwkeuriger gelukkig.
/FP Schrijft volledig paden weg naar de log... ik veronderstel dat hij als je dat niet doet enkel de bestandsnamen zet wat het moeilijk maken zou.
/TS toont tijdsstemels van de bestanden ook in de logfile.
/tee toont de logfile ook op de console terwijl hij bezig is
/XD "X:\System Volume Information" sluit de opgegeven map (in dit geval system volume information op station x) en alles wat er onder ligt uit.
:strip_icc():strip_exif()/u/8334/freebsd.jpg?f=community)
/u/45013/GoT%2520-%2520QR.png?f=community)
:strip_icc():strip_exif()/u/4167/bacall8.jpg?f=community)
