Copy disregarding timestamp (MD5 Hash more important?)

What is the problem you are having with rclone?

I've just started to use rclone, so excuse me if I'm missing something obvious.

It appears that the MD5 hash is prioritised over modified time when using copy on a local filesystem. I'm attempting to keep a local copy in "sync" with the same folder at work, but using copy as I don't want any files to be deleted. The remote share is mounted via SMB once I'm connected to the VPN. I first copy from the network volume to the local copy and then do the reverse. This is because others are adding to our work server but we're all creating large files we need to keep a local snapshot but also push and pull changes/updated files.

The issue appeared when I had to overwrite a local version of a file to fix something. The timestamp and hash was obviously different between the two. Since I've scripted everything, the first command is always from the network share to local. Despite the large time difference, rclone decided to copy the older (network share) version and override the newer (local) version which meant the second command didn't do anything as now it's the same file.

I'd love to know what I'm doing wrong as, logically, it should work and only be pushing and pulling new or updated files.

Thank you.

The command you were trying to run (eg rclone copy /tmp remote:tmp)

First command (network mount to local):
rclone copy --progress /Volumes/jobs/XXX /Volumes/Samsung_T5/jobs/XXX

Second command (local to network mount):
rclone copy --progress /Volumes/Samsung_T5/jobs/XXX /Volumes/jobs/XXX

A log from the command with the -vv flag (eg output from rclone -vv copy /tmp remote:tmp)

Using the commands above but with --vv and -dry-run, I get the following lines about the file in question.
Note: This is a dry-run after I try to reporduce the issue w/ an updated file on the local folder.

First command:
DEBUG: Modification times differ by 115h48m6s: 2020-04-09 15:57:00 +0200 CEST, 2020-04-14 11:45:06 +0200 CEST
DEBUG: MD5 = 093782d626d990711bf6bab1027008c9 (Local file system at /Volumes/jobs/XXXXX/films/chen/masters)
DEBUG: MD5 = 40eb7f55d47ad153cdd1eaae5fffb005 (Local file system at /Volumes/Samsung_T5/jobs/XXXX/films/chen/masters)
DEBUG: MD5 differ
INFO : Local file system at /Volumes/Samsung_T5/jobs/XXXX/films/chen/masters: Waiting for transfers to finish
NOTICE: Not copying as --dry-run

Second Command:
DEBUG : Modification times differ by -115h48m6s: 2020-04-14 11:45:06 +0200 CEST, 2020-04-09 15:57:00 +0200 CEST
DEBUG : MD5 = 40eb7f55d47ad153cdd1eaae5fffb005 (Local file system at /Volumes/Samsung_T5/jobs/XXXX/films/chen/masters)
DEBUG : MD5 = 093782d626d990711bf6bab1027008c9 (Local file system at /Volumes/jobs/XXXX/films/chen/masters)
DEBUG : MD5 differ
INFO : Local file system at /Volumes/jobs/XXXX/films/chen/masters: Waiting for transfers to finish
NOTICE: Not copying as --dry-run

What is your rclone version (output from rclone version)


Which OS you are using and how many bits (eg Windows 7, 64 bit)

OS/X 10.14.4

Which cloud storage system are you using? (eg Google Drive)

Local & SMB mount via VPN

Rclone will copy files if the timestamps are different by default. It doesn't care whether they are older or newer.

I think you probably want this flag if I'm understanding you correctly (try with --dry-run first)

-u, --update Skip files that are newer on the destination.

1 Like

Thank you, that is exactly what I was looking for. I'm used to how rsync works so I would have thought that older files don't overwrite newer ones but I can see how that's more of a sync than copy (i.e. replace) idea.

1 Like

Rsync works in exactly the same way as rclone and even has the same -u/--update flag :slight_smile: They say plagiarism is the sincerest form of flattery!

This topic was automatically closed 60 days after the last reply. New replies are no longer allowed.