Fixed! ROBOCOPY Usage on Linux EXT2 / EXT 3 File Systems
For some time, I have been a fan of the robust copy feature that has been available for several Windows releases including Windows XP, Windows 2003, and of course Windows Vista. In fact, I changed from using programs like SecureCopy or built previously built in utilities like cp (copy) or xcopy.
In fact my primary to secondary disk backup method for some time has been to use the following command syntax to mirror directories to the backup drives:
ROBOCOPY "C:\My Music" "B:\Backup\My Music" /MIR
With the above syntax, it creates an exact mirrored copy of the data in the directory "C:\My Music" and copies (purging deleted files and directories) the entire tree to "B:\Backup\My Music". This works like a charm on NTFS files systems.
Now enter into the picture my new NAS device which is running a Linux based EXT2 / EXT3 file system and we start to see some problems. I first noticed the symptoms I saw is that when I was testing out the backup copies to the new location on that Linux based network attached storage device. Specifically speaking, I would see the identical file being copied over and over again.
Thinking that it most likely had to do with either an archive bit or similar type backup issue, I first tried adding the /M switch to the command line to forcibly set the archive bit with every file.
That new syntax looked like: ROBOCOPY "C:\My Music" "B:\Backup\My Music" /MIR /M
However, that was not much of a help -- so my attention turned to the Linux EXT2 / EXT3 file system structure. Some research by entering "robocopy ext2" into Google revealed some information buried ironically within a NetGear message board. The posts revealed the following information about inodes that I was not too familiar with:The standard ext2/ext3 inode has 3 time fields, last inode change, last file data change and deletion time. These timestamp fields have a resolution of 1 second. The only time field that maps from NTFS to ext2/ext3 is the file data modification time.
That revealed the issue -- the NTFS timestamp was more precise than the resolution for the EXT2 / EXT3 inode file systems. Therefore, a different option had to be tweaked with ROBOCOPY to allow for a less precise timestamp measurement.
Fortunately, out of the box there is a /FFT switch for ROBOCOPY which specifically accomplishes this task by assuming FAT File Times which translates to a more forgiving 2-second granularity. This is more than sufficient to account for the one-second granularity that the EXT2 / EXT3 file systems support.
So, I modified my backup command one more time by adding '/FFT' to the end of the command:
ROBOCOPY "C:\My Music" "B:\Backup\My Music" /MIR /FFT
I gave the command a couple of tests and bingo, that solved the problem of the same files copy over and over again. If you are encountering a similar issue, then most likely the /FFT switch may resolve issues that you have copying files between NTFS and other non-NTFS systems including Linux and others.
Good luck!




