On Tue 01 Mar 2016 20:53:17 NZDT +1300, Barry wrote: > The Ext3 fs is on an internal HD, the dos FS is on a usb drive for > the purposes of compatability with an inferior box running an > inferior system. I have now run rsync in test mode between the major > directories and it returned no errors so I guess... all is well.
I don't believe rsync -n does the integrity test you are after. rsync -c would. In any case, there are additional problems with using rsync on a braindead FS like dosfs (or vfat): 1) Time stamp granularity is only 2s, not 1s, or nanoseconds like Linux filesystems had for a long time. Originally the rsync protocol could not transfer the sub-second part of time stamps, so they were zeroed out on the copy (even if both source and destination were local). To decide whether a file needs copying rsync by default only looks at name, size, permissions and time stamp - if they're all equal the file is untouched! Only the seconds of the time stamp were compared - a difference in the sub-second part is invisible to rsync. With this dosfs rubbish you get the interesting effect of every second file (statisticaly) being copied on every rsync run, because dosfs stamps are rounded/truncated to the nearest 2s! Hint: that's what --modify-window=2 is for. 2) This historic Billyshite(TM) is completely unable to handle daylight saving!!! And write in capitals on a note to your monitor "THERE IS NO SOLUTION". It's broken by design. Just wait until daylight saving finishes on 3 April, and start swearing your living daylights, because the times for half of the year are out by 1h. You guessed it: on 25 Sep it's the other half. If you're lucky, running the dumb FS on UTC fixes some of the problems, but not if you have a system running on UTC (e.g. your digital camera). This depends on mount options, and they can only be overridden in one direction. You may play with http://volker.top.geek.nz/soft/odd/ This makes using rsync on dosfs a dangerous proposition, especially with -u, which you'd normally always use. 3) Count the weeks until that useless FS is corrupted. The bigger the disk, the bigger the mess. It is unsuitable as backup. You could try and use it for file transfer only - if you don't mind having part of your metadata screwed up. 4) You already know that it doesn't store/copy your Linux permissions etc. See suitability as backup above. (Suitability for anything yadda yadda android crapola yadda) Your method of using rsync for checking integrity is inefficient too, and it only gives you an answer at one point in time. The much better thing to do is to store checksums in your directories somewhere near the top level. Not only can you verify a copy operation faster than rsync -c, you can also do this any time again later, even if the master copy has been updated. I made a script for that decades ago and would never consider creating backups without checksums. Create checksum for all files in current dir, recursively: md5 -i . Check: md5 -C . It's in scriptutils, http://volker.top.geek.nz/soft/pck/ HTH, Volker -- Volker Kuhlmann http://volker.top.geek.nz/ Please do not CC list postings to me. _______________________________________________ Linux-users mailing list [email protected] http://lists.canterbury.ac.nz/mailman/listinfo/linux-users
