3

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:

<f..t...... extSdCard/foo/bar

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?

Improve this question
2
  • 1
    For the record, the field known as ctime on UNIX/Linux systems is not creation time. It is the time that the inode (the file metadata) was last changed. Creation time traditionally did not exist on UNIX/Linux filesystems so there was to means of collecting it from NTFS filesystems. Newer Linux-based systems can now access creation time as btime (birth time)
    – Chris Davies
    Commented Oct 30, 2020 at 9:10
  • The reason for this comment ↑ is because ls -c as mentioned in the question orders by and shows ctime, which is not the file creation time shown on NTFS file systems
    – Chris Davies
    Commented Oct 30, 2020 at 9:12

2 Answers 2

Reset to default
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.

Improve this answer
3
  • 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
    Commented Nov 12, 2013 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
    Commented Nov 12, 2013 at 10:42
  • ctime is NOT creation time. rsync doesn't care about either ctime (metadata change time) or the relatively new btime (birth/creation time). It uses file size, and mtime for an efficiency shortcut or checksums otherwise
    – Chris Davies
    Commented Mar 14, 2023 at 8:23
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.

Improve this answer
3
  • 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
    Commented May 21, 2019 at 21:03
  • 1
    ctime is NOT creation time
    – Chris Davies
    Commented Mar 14, 2023 at 8:22
  • You're correct. It's "change" time, and it represents the time that any aspect of the file — contents or metadata — changes. Furthermore, it can't be changed the same way that atime and mtime can. I can't say for sure what ctime is on Windows.
    – Edward Falk
    Commented Mar 14, 2023 at 15:08

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .