Renaming a file doesn't preserve its timestamp on Google Drive

Bugs and issues Linux
#1

Hi,

I have noticed that renaming a file locally sets the file’s timestamp to the time of renaming the file instead of preserving the original timestamp.

Not sure if this bug was introduced recently or has been here the whole time.

Steps to reproduce (Linux command line):

  1. touch A # Creates a new file with the mtime T, uploads it to Google Drive with “modification time” set to T
  2. sleep 300 # Wait 5 minutes
  3. mv A B # Renames the file.
  4. Wait a few moments for the change to get synced and check B’s “modification time” on drive.google.com . The new file’s timestamp is now T+5 minutes instead of T. This is also reflected locally if the folder is unsynced and re-synced again.

Ubuntu Linux, insync v3.2.1.40839

#2

Hi! Clarifying this behavior with our team. I’ll update you!

#3

Hi! Sorry took a while, but this has been fixed in 3.2.3: New Insync version: 3.2.3 :slight_smile:

#4

Awesome, I will give it a try today. Thank you

#5

Hi,

This is still not fixed - I would say it is worse now
Version 3.2.3 will synchronize the timestamp but to the newer one instead of leaving the timestamp as it is.

When a file is renamed, its timestamp should stay the same. Upon renaming,

  • version 3.2.1 left the old local timestamp (good), but set the cloud “modification time” to the time when the file was renamed (wrong)
  • version 3.2.3 upon syncing sets both local timestamp and cloud “modification time” to the time when the rename happened (both wrong)

The proper way to fix it is to leave the local file alone and make sure the cloud file has the same “modification time” as the local file (time when the file was actually modified, not renamed).

Hope this helps.

#6

Hi, new user here. I almost paid for a new license (with the Black Friday discount) when I saw this. Did a few tests with the newest version (3.3.2) just now and confirmed this problem is still there.

The way Insync 3.2.3 did it (changing local timestamp to matched the one on Google Drive) was no better, but reversing the change (in 3.2.5) is not the solution either.

Yes, it’s Google Drive that changes timestamps for renamed files. But Syncovery, FreeFileSync and Mountain Duck does it right: they all change the timestamps back to match those on local drives.

(If you happen to agree with Google, then please at least make it an option.)

I rename my files often, so I can’t use Insync before this is corrected. Pity.

2 Likes
#7

I have always been annoyed that renaming a file in the Google Drive UI causes the modification timestamp to update. It’d be interesting and indeed probably better if Insync did keep local modification times synced with the Google Drive time (overwriting Google’s overzealous timestamp updating…).

1 Like