2

I've been using rsync for Android to backup my phone to a remote NTFS filesystem on a Linux system for a while.

Recently, the HDD containing the NTFS filesystem has started to fail (or throw "I/O Errors") so I took the opportunity to copy all the files onto a new HDD and new NTFS filesystem. In this instance I used the "FastCopy v2.11" tool for Windows.

My problem is that when I do an rsync "dry run" I can see that it wants to recopy files which already exist on the remote rsync folder. For example, when I run with "-iv" I get this kind of output:

Which, as I understand it means that rsync wants to copy this file to the remote rsync because of a timestamp difference.

The strange thing is that if I use "Astro" for Android to look at the local file properties, I can see that the file's size, modified time, and MD5 checksum are exactly the same as that of the remote file (using ls -l to check the modified time).

Given that I recently copied the remote rsync files from an old NTFS filesystem, the remote file's ctime is different (using ls -lc).

Does rsync look at the remote ctime, and if so is there any way I can use rsync, or ntfs-3g to get around this problem?

0

By default rsync relies on the mtime/ctime and size for file comparison, but if you use the -c flag it would ignore them and use content checksums.

The problem is this way can be much slower(those checksums might be really expensive to calculate on your mobile device) and you might need to always run it like this from now on, so it might make sense to just let it run once without checksums, let it do its thing so it copies everything once again based on the mtime/ctime/size comparison method it uses by default, but at least next times you won't spend time calculating checksums.

  • Thanks Cristian. I had looked at the checksum option but wanted to explore other possibilities for the reason you mention. Especially given that the remote linux rsync host is a Raspberry Pi at the moment! Maybe I should temporarily mount both filesystems on a faster linux system (laptop/desktop) and then do a local rsync based on the checksum algorithm, and then return the filesystems to their respective places from there on... – wombat Nov 12 '13 at 10:37
  • I guess the other option is to find or write a utility which can set my file ctime to the same value as the file mtime. Or maybe get the rsync source code and build my own version which can be instructed to only consider "size and mtime" in its quick check algorithm? – wombat Nov 12 '13 at 10:42
0

I just did a quick experiment; rsync compares mtime and ignores ctime (on Mac, at least.) Unfortunately, Windows file systems only have ctime, which they return for atime and mtime as well.

This is why rsync is so aggressive about copying files from Windows file systems that don't need to be copied — the mtime on the Unix file is being compared to the "ctime" on the Windows file.

  • 1
    I am curious about that. What do you mean by "Windows file systems only have ctime, which they return for atime and mtime as well"? If one right-click on a file and go to properties, one will get all 3 different values, right? Or are there other situations where only one and the same value is returned? I am wondering if I have a related problem here: unix.stackexchange.com/questions/519547/… – The Quark May 21 at 21:03

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.