Workaround for preserving dates

Google Drive modifies the creation/modified dates of incoming files with the date rclone copy ran.

Of-course, this isn’t helpful for archiving and future-proofing needs. I tried zipping folders to unzip at destination yet that requires Add-Ons and not automated.

I can’t seem to think of another workaround. Is this even remotely possible with rclone? I don’t mind tweaking a little code if I must.

My research shows other cloud providers have this issue, even beyond rclone. I’ll have to work on another solution if dates can’t be preserved.

Can you explain a bit more please the problem you are having?

rclone sets the modification time of files it uploads to be that of the file so timestamps will be preserved (note that drive only has times accurate to 1ms).

$ echo hello > z.txt
$ rclone copy z.txt drive:testz
$ rclone lsl drive:testz
        6 2017-08-31 10:05:20.349000000 z.txt
$ ls --full-time -l z.txt 
-rw-rw-r-- 1 ncw ncw 6 2017-08-31 10:05:20.349891285 +0100 z.txt

The last modified date appears in the drive Web interface too.

It does??

The times I see in Google Drive are the times it receives the files the source server.

I clarified my understanding to realise the modified dates are preserved (my apologies), however Drive seems to be creating it’s own creation dates since they happen to be non-exist with all files/folders on the server. That’s not a major issue as long as they can be the same as ‘modified’.

Speaking of such, transferring folders (the bulk of my rclone copy work) requires that I recreate the directory on the remote end. Doing so means that the modified time is not the same as the source. Is there really not a means to just copy a directory with rclone, thereby preserving all dates as is?

I then double-checked dates when I download files/folders from Drive to find the modified date is even stripped so the files are dated at the time of download (via browser). Downloading files FTP direct preserves the dates (making the blank ‘create’ equal to modified), yet I did ensure both my clients (FileZilla & Cyberduck) preserved them, and they apparently do for uploads (untested by myself).

I think I have gaps in my understanding of all the technologies here than a limitation of rclone? Google Drive isn’t a service I’ll be using forever of-course, so it’s important the dates aren’t stripped/manipulated inbetween systems. rClone is a godsend, even if I can’t get the dates right :stuck_out_tongue:

Unfortunately you can’t set the creation date on drive files, only the modified date.

rclone will preserve the modification dates, here is an example…

$ cd t3
$ ls -alrt
total 76
drwxrwxr-x  2 ncw  ncw   4096 Aug 31 21:05 .
drwxrwxrwt 41 root root 69632 Aug 31 21:05 ..
$ cp -av /usr/share/doc/lsb-release/README.Debian z
'/usr/share/doc/lsb-release/README.Debian' -> 'z'
$ stat z
  File: z
  Size: 1540      	Blocks: 8          IO Block: 4096   regular file
Device: fd01h/64769d	Inode: 6169878     Links: 1
Access: (0644/-rw-r--r--)  Uid: (  502/     ncw)   Gid: (  502/     ncw)
Access: 2017-03-30 17:40:12.000000000 +0100
Modify: 2014-05-27 15:13:24.000000000 +0100
Change: 2017-08-31 21:06:29.465673695 +0100
 Birth: -
$ cd ..
$ rclone -v copy t3 drive:t3
2017/08/31 21:07:04 INFO  : Google drive root 't3': Modify window is 1ms
2017/08/31 21:07:04 INFO  : Google drive root 't3': Waiting for checks to finish
2017/08/31 21:07:04 INFO  : Google drive root 't3': Waiting for transfers to finish
2017/08/31 21:07:08 INFO  : z: Copied (new)
2017/08/31 21:07:08 INFO  : 
Transferred:   1.504 kBytes (259 Bytes/s)
Errors:                 0
Checks:                 0
Transferred:            1
Elapsed time:        5.9s

$ rclone -v copy drive:t3 t3.copy
2017/08/31 21:07:18 INFO  : Local file system at /tmp/t3.copy: Modify window is 1ms
2017/08/31 21:07:19 INFO  : Local file system at /tmp/t3.copy: Waiting for checks to finish
2017/08/31 21:07:19 INFO  : Local file system at /tmp/t3.copy: Waiting for transfers to finish
2017/08/31 21:07:19 INFO  : z: Copied (new)
2017/08/31 21:07:19 INFO  : 
Transferred:   1.504 kBytes (829 Bytes/s)
Errors:                 0
Checks:                 0
Transferred:            1
Elapsed time:        1.8s

$ stat t3.copy/z 
  File: t3.copy/z
  Size: 1540      	Blocks: 8          IO Block: 4096   regular file
Device: fd01h/64769d	Inode: 6185463     Links: 1
Access: (0664/-rw-rw-r--)  Uid: (  502/     ncw)   Gid: (  502/     ncw)
Access: 2014-05-27 15:13:24.000000000 +0100
Modify: 2014-05-27 15:13:24.000000000 +0100
Change: 2017-08-31 21:07:19.697592073 +0100
 Birth: -
$

However rclone doesn’t preserve the modification dates of folders if that is what you are trying to do.

That is really important to me too! I think rclone does the right thing in trying hard to preserve the modification date (which is what shows for ls etc).

Hello,

If we transfer data using Google Drive file steam the dates of files and folders are preserved but not with Rclone. I wonder if they have opened up something new in the API since and maybe third party products like Rclone could take advantage?

Thanks

The dates of files should definitely be preserved with rclone. The dates of folders won’t be though.