Wrong modification timestamps in Google Drive

I have been syncing across Team Drives using --max-age for filtering files to be synced. During this, I noticed some files were being transferred which shouldn't fall within the max-age set.

To confirm whether this was an issue with the filtering or something on the drive itself, I checked via the WebUI and it seems to show a very wrong modification time of Jul 28, 2017, by <user> when the created at date is Jun 28, 2019.

This is almost a 2-year difference. Any thoughts on this could have happened?

Are they two different things though? The file can be created on the 28th on Google Drive, but modification time would be kept.

[felix@gemini ~]$ ls -al /etc/hosts
-rw-r--r-- 1 root root 243 May 16 11:52 /etc/hosts
[felix@gemini ~]$ rclone copy /etc/hosts GD:
rclone lsl [felix@gemini ~]$ rclone lsl GD:hosts
      243 2019-05-16 11:52:08.698000000 hosts


You can see the mod time of May and in GD speak, it was created just now.

Makes sense if it's just keeping the original file(s) modified timestamp, but doesn't it seem logically wrong to have a greater created at timestamp than the modified timestamp?

I mean, I can see either way but I believe the problem is the created date can't be set of GD as the only thing available is the modified date so that is what gets set and what the mount uses as well.

Got it. Thanks.

So, this becomes a feature request instead. Can we have filtering based on the created timestamp as an option too?

You can use:


Instead of the modified time.

[felix@gemini ~]$ rclone lsl GD:hosts --drive-use-created-date
      243 2019-07-02 15:46:16.233000000 hosts
[felix@gemini ~]$ rclone lsl GD:hosts
      243 2019-05-16 11:52:08.698000000 hosts
1 Like

That solves my issue. Thanks a lot.

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