rsync modifies time stamps of the source!

[vicente95650]

If I execute a simple rsync command ( e.g. rsync -a <source_file> <dest_file> ) within a shell, the time stamps (access time, modify time; change time) of the source file are modified (changed to the current time) !

In other words, after the rsync, the source file appears newer than the destination file!

I am now on freenas-9.10.1-u2 but I first noticed this on freenas-9.3.

A brief search did not reveal this as a known bug. Can someone corroborate?

 

[melloa]

Don't see this here:

rsync files:

Original files:

 

[vicente95650]

melloa, thanks for checking. I apologize that I did not provide sufficient information on the conditions under which I observed the problem. I experienced the problem when the source was a USB-connected disk with NTFS format ; which I mounted, after executing kldload fuse, using ntfs-3g. The destination is a zfs dataset. I had resorted to using rsync because I experienced problem using the freenas Import feature.

I do not see the problem when the source is a ZFS dataset.

 

[fracai]

This would seem to point to a deficiency in the NTFS driver. It's likely that in the attempt to update the access time, the driver is updating the modify and change as well.

Anyway, you can work around this by using the "-c" argument with rsync. This will ignore the modify time and file size when comparing files, relying just on the file checksum. It'll likely take longer to check everything, and will probably still modify the timestamps, but you'll be able to do incremental transfers.

You could also probably mount the drive as read-only to avoid modifying the timestamps.

 

[pirateghost]

melloa, thanks for checking. I apologize that I did not provide sufficient information on the conditions under which I observed the problem. I experienced the problem when the source was a USB-connected disk with NTFS format ; which I mounted, after executing kldload fuse, using ntfs-3g. The destination is a zfs dataset. I had resorted to using rsync because I experienced problem using the freenas Import feature.

I do not see the problem when the source is a ZFS dataset.

so you mounted a disk, outside of the GUI, and loaded fuse and ntfs-3g manually, and wonder why it did things to your source disk....

Interesting.

 

[vicente95650]

This would seem to point to a deficiency in the NTFS driver. It's likely that in the attempt to update the access time, the driver is updating the modify and change as well.

Anyway, you can work around this by using the "-c" argument with rsync. This will ignore the modify time and file size when comparing files, relying just on the file checksum. It'll likely take longer to check everything, and will probably still modify the timestamps, but you'll be able to do incremental transfers.

You could also probably mount the drive as read-only to avoid modifying the timestamps.

Your suggestion sounds like a safer way to use rsync especially in my case where I basically want to make a one-time-only copy of my NTFS disk. I intend to try it and see if any attribute of the source files/directories are modified.

 

[pirateghost]

I am pretty confused on why you aren't using the built in mount in the GUI to import data.

http://doc.freenas.org/9.10/storage.html#import-disk

 

[vicente95650]

so you mounted a disk, outside of the GUI, and loaded fuse and ntfs-3g manually, and wonder why it did things to your source disk....

Interesting.

I only did this because I had used Import Disk on freenas9.3 and the import did not work. If you have a recommendation on how to properly mount the disk and use ntfs-3g I would very much appreciate hearing it.

 

[pirateghost]

I only did this because I had used Import Disk on freenas9.3 and the import did not work. If you have a recommendation on how to properly mount the disk and use ntfs-3g I would very much appreciate hearing it.

use a client computer or the built in import function. do not fiddle around with the FreeNAS CLI unless you understand the ramifications.

 

[vicente95650]

I am pretty confused on why you aren't using the built in mount in the GUI to import data.

http://doc.freenas.org/9.10/storage.html#import-disk

It appears as if we were both typing at the same time. I read that there was a problem with Import Disk in freenas9.3 which was not worth fixing. I have tried Import Disk on freenas9.10 and after waiting for several hours decided to abort. I plan to repeat the import tonight and hopefully the Import Disk will complete.

 

[vicente95650]

use a client computer or the built in import function. do not fiddle around with the FreeNAS CLI unless you understand the ramifications.

I understand. I thought I understood the ramifications of using rsync the way I did on a freenas system, at least as they pertain to the source of the rsync, but it seems clear that I did not.

 

[pirateghost]

I understand. I thought I understood the ramifications of using rsync the way I did on a freenas system, at least as they pertain to the source of the rsync, but it seems clear that I did not.

It's not the ramifications of rsync, it is the ramifications of mounting a disk that the GUI doesn't know about. This is a NAS appliance. Fooling around with disks outside of the intended GUI is bad.

 

[vicente95650]

It's not the ramifications of rsync, it is the ramifications of mounting a disk that the GUI doesn't know about. This is a NAS appliance. Fooling around with disks outside of the intended GUI is bad.

Ok. I will report back after I try Import Disk once more.

 

[Stux]

Your suggestion sounds like a safer way to use rsync especially in my case where I basically want to make a one-time-only copy of my NTFS disk. I intend to try it and see if any attribute of the source files/directories are modified.

Can you not mount it read only?

 

[vicente95650]

Can you not mount it read only?

Yes, this is what fracai suggested, and what I plan to try if the Import Disk from the GUI does not work, although I got the impression from pirateghost that it is dangerous to mount disks from outside of the GUI. I was also considering using cp instead of rsync although if it is the NTFS driver that is causing the problem the cp may have similar problems.

I started Import Disk (250GB of data) into a newly created dataset from the GUI 16 hours ago and it has not yet completed. I plan to wait one more day before aborting.

 

[pirateghost]

For a mere 250gb I would use a client machine and push it across the network.

 

[vicente95650]

For a mere 250gb I would use a client machine and push it across the network.

The main reason that I am exploring other ways to get data from NTFS drives is that I do have other larger drives.

It appears that the Import Disk did complete after all (ntfs-3g unmounted the source disk after 5 hours) even though the GUI still has the Import Disk progress window waiting for me to "Abort" or "Run In Background". Is it safe to close the progress window?

 

[vicente95650]

Well, I decided to click the "abort" button and the Import Disk progress window (which gave no indication of how much progress had been made) disappeared.

The file /var/log/messages gives no indication that anything went wrong, and ntfs-3g did unmount the source disk after 5 hours.

From what I can tell, The "Import Disk" process appears to have succeeded. The imported files and directories do exist at the target dataset, and their time stamps appear to be correct.

I did notice that the NTFS disk was mounted read-only, a precaution that no longer appears to be redundant but rather essential!