PDA

View Full Version : Robocopy help, please



Kyle
2006-11-05, 09:17
I backup my entire folder of FLAC files from time to time, using Robocopy. I use the mirror function. I have added some new music since the last backup, but Robocopy is copying every single file in my music folder. Here is a sample of the report:


-------------------------------------------------------------------------------
ROBOCOPY :: Robust File Copy for Windows :: Version XP010
-------------------------------------------------------------------------------

Started : Sun Nov 05 09:40:35 2006

Source : e:\flac files\
Dest = f:\backup flac files\

Files : *.*

Options : *.* /TEE /S /E /COPY:DAT /PURGE /MIR /NP /R:1000000 /W:30

------------------------------------------------------------------------------

0 e:\flac files\
0 e:\flac files\Aaron Neville\
15 e:\flac files\Aaron Neville\Bring It On Home\
Older 30.0 m 01 - Rainy Night In Georgia.flac
Older 21.4 m 02 - Ain't No Sunshine.flac
Older 29.6 m 03 - (Sittin' On) The Dock Of The Bay.flac
Older 22.9 m 04 - Stand By Me.flac
Older 23.9 m 05 - You Send Me.flac
Older 29.7 m 06 - Respect Yourself.flac
Older 21.5 m 07 - When A Man Loves A Woman.flac
Older 25.0 m 08 - Let's Stay Together.flac
Older 23.9 m 09 - It's All Right.flac
Older 25.7 m 10 - People Get Ready.flac
Older 23.4 m 11 - My Girl.flac
Older 25.4 m 12 - Ain't That Peculiar.flac
Older 25.1 m 13 - A Change Is Gonna Come.flac
Older 26.1 m 14 - (Your Love Keeps Lifting Me) Higher And Higher.flac
Older 10322 cover.jpg


Is it saying that the files on the E-drive (source) are older, or the files on the F-drive (destination) are older? I certainly haven't changed all of my files. Is it getting some type of timestamp data? Could Slimserver have changed the timestamp on all of my files? This really worries me because earlier this year I lost all of my music files and had to start over. I really don't want that to happen again.

JJZolx
2006-11-05, 10:36
Robocopy uses the file modified times. It's saying that the source files are older than the destination files, so it's copying from the source to the destination. That's the idea behind the /MIR option - to make the destination exactly the same as the source.

Does it do this if you rerun the backup operation? If so, something is wrong. My guess would be that you modified the files in your backup directory, maybe by mistake while you were updating some tags.

SlimServer doesn't modify the music files in the library in any way. It can modify and save playlists, but not music. Even if it did, those files would likely then be _newer_ than the backup files, not older.

Kyle
2006-11-05, 11:45
Yes, I've changed some tags and added some albums, but not ALL of them. I probably backed up the hard drive using the same program a couple of months ago. How could the source files be older than the destination when the destination files came from the source files originally? Is there some function I could have done that changed the timestamp on all of those files at once?

JJZolx
2006-11-05, 12:02
Yes, I've changed some tags and added some albums, but not ALL of them. I probably backed up the hard drive using the same program a couple of months ago. How could the source files be older than the destination when the destination files came from the source files originally? Is there some function I could have done that changed the timestamp on all of those files at once?
Like I said, maybe you mistakenly modified the tags of the files in the backup. I've done that once or twice. Otherwise, the source files should not be older than the backups.

Kyle
2006-11-05, 15:18
Yes, somehow the timestamps changed. I just can't figure out how they could have all changed. I sure haven't retagged 5,000 songs. I have used the backup file to transfer all of my music files to a third hard drive, also using Robocopy on my laptop computer. Could such an operation alter all timestamps at once? If it's something I have done wrong, I'd like to figure it out. I don't want to jeopardize my files, and it took several hours to overwrite them all.

Dave2
2006-11-05, 17:38
>"Yes, somehow the timestamps changed. . . ."

Are they all one hour off? See, e.g., http://en.wikipedia.org/wiki/NTFS ("For historical reasons, the versions of Windows that do not support NTFS all keep time internally as local zone time, and therefore so do all file systems other than NTFS that are supported by current versions of Windows. However, Windows NT and its descendants keep internal timestamps as GMT/UTC and make the appropriate conversions for display purposes. Therefore, NTFS timestamps are in GMT/UTC. This means that when files are copied or moved between NTFS and non-NTFS partitions, the OS needs to convert timestamps on the fly. But if some files are moved when summer or "daylight saving" local time is in effect, and other files are moved when winter or "standard" local time is in effect, there can be some ambiguities in the conversions. As a result, especially shortly after one of the days on which local zone time changes, users may observe that some files have timestamps that are incorrect by one hour.").

ipy
2007-03-24, 18:21
I experienced a similar thing after Sydney daylight saving ie: tried to do a backup & the "older" (source) was overwriting newer (destination) files.

To overcome this I set my switches to the following:
robocopy "M:\my music" "J:\my music" /E /MAXAGE:1
seems to be working so far........

Kyle
2007-03-24, 18:45
I think the Daylight Savings Time change was the cause of my problem. What does the MAXAGE command mean?

ipy
2007-03-24, 19:16
I think the Daylight Savings Time change was the cause of my problem. What does the MAXAGE command mean?

/MAXAGE:n : MAXimum file AGE - exclude files older than n days/date.##

Just means I 'm restricting any updates from my source to the backup drive to files newer than a day or not older than a day. Files will be be ignored if it does not meet this criteria.

peter
2007-03-25, 03:46
Kyle wrote:
> I think the Daylight Savings Time change was the cause of my problem.
>

Yeah, that DST stuff is a nuisance. I had a cron job scheduled for 02:00
last night, but there was no 02:00... :(

I moved it to 01:00 so it won't get executed twice when DST gets
switched off again.

Regards,
Peter

Citylights
2008-11-02, 23:05
Try the /FFT switch to ignore timestamp differences of up to 2 seconds.

This will help if you are copying from NTFS to non-NTFS partitions. Perhaps your F: drive?
RoboCopy will look for a timestamp accurate to 100 nanoseconds if it thinks it is copying to NTFS. Most other file systems do not use such an accurate timestamp.


This solved my problem of backing up from XP to my Linkstation NAS (formatted with the xfs file system).

Kyle
2009-03-12, 23:01
This issue has come up again with DST. What is the best solution, and how do I add it to my command file?

scrubby
2009-03-13, 04:33
DST is definitely your issue here. I use robocopy a ton and one thing I have exploited in the past is the equivalency of "/mir" to "/e /purge" as these two switches are essentially the same. With "/e /purge", however, you can also use any of the other combinations of switches on your command line whereas "/mir" is more limited. In your case I would suggest playing around with "/e /purge" in combination with the "/maxage" switch.

Also, one more thing I like to use is to add the "/v" and "/l" switches because this will simply list the STDOUT of the command without actually doing the work. That way you can "see" what is going to happen and fool around with your settings without actually doing any of the work.

Hope that helps and good luck!
Scrub

Kyle
2009-03-13, 04:58
DST is definitely your issue here. I use robocopy a ton and one thing I have exploited in the past is the equivalency of "/mir" to "/e /purge" as these two switches are essentially the same. With "/e /purge", however, you can also use any of the other combinations of switches on your command line whereas "/mir" is more limited. In your case I would suggest playing around with "/e /purge" in combination with the "/maxage" switch.

Also, one more thing I like to use is to add the "/v" and "/l" switches because this will simply list the STDOUT of the command without actually doing the work. That way you can "see" what is going to happen and fool around with your settings without actually doing any of the work.

Hope that helps and good luck!
Scrub

Can you give me the syntax? Say "e:\flac files" is the source and "f:\backup flac files" is the destination.

scrubby
2009-03-13, 06:53
Can you give me the syntax? Say "e:\flac files" is the source and "f:\backup flac files" is the destination.

Sure... try this:

robocopy "e:\flac files" "f:\flac\backup flac files" /v /e /purge /maxage:10 /l

In this instance your copy would only copy files that are new within the last ten days. Using the "/v" switch will show you everything it does so be sure to have adequate buffer in your command line shell for all your file listings. Those files that are older than ten days will have the text "too old" next to them, and they will show up cumulatively in the "skipped" section at the end. When you are satisfied that the results are what you want, simply remove the "/l" at the end there and then the work will be performed.

Your original post had "/mir" together with other switches; robocopy hates that and will only work with your "/mir" switch. nice option handling, eccch!

One last thing - I am using the robocopy that comes with Vista so your switches may vary. Use the "/?" switch to get the full compliment of options available to you if you don't know what is at your disposal already.

Scrub