LinkedIn
Twitter
One of the best ways to submit bugs/feedback on a Google product is via the "Send feedback" in the product itself. So, for Google Drive for Desktop on my Mac, that looks like this:
In my experience from other unrelated bugs, it often takes a minimum of several months between a bug being identified and it getting fixed (and Google is far from alone in that -- it seems to be pretty typical across the industry, sigh).
Hope that helps, at least a little,
Ian
I want to add some weird findings noted today:
On Google Drive web the date seems correct:
However in Google Drive client (Windows Explorer), it shows 2022:
How is this possible?
I have found the local Google Drive for desktop cache (which is stored in an sqlite database) often contains incorrect file times (probably due to other bugs besides the known issues documented here).
[UPDATE] The "Refresh folder" menu item mentioned below did NOT work for my test (rename a file, the local cache time was showing 2019 and the cloud time was showing 2022. "Refresh folder" did not update the out-of-sync local modified time with the cloud time. So, unless someone else knows another technique, the only way I know is to delete your entire local cache which will then be repopulated with the modified file times that are in the cloud.
(see update above)...You can try to force a refresh on a single folder by holding [SHIFT] and right click the folder which contains your file and select "Refresh folder":
Hi, here is the result:
As you can see all 3 values show 2022. Which effectively make me loose completely the original creation date (which was in 2008) and modification date (which was in 2015).
As a matter of fact the file was NOT modified in 2022, it was "merely" uploaded or transferred to Google. I would agree that the accessed date would changed to 2022 because indeed it was accessed.
But I disagree the creation date or modification date would change. The file was NOT modified and in fact the checksum is the same.
IMO "uploading" should not be regarded as "creation" or "modification" if a prior date is already existing. (Of course arguably if no date exists Google could allocate the date of the day, but in the case of Windows Explorer it exists and should not be altered).
So, finally I had some time to dedicate to this. Here we go...
The following conclusions derive from several tests (across several scenarios) of 4 different operations:
- First-time copy or sync to โMy Driveโ or a Shared Drive
- Syncing from a specified local folder (visible under โComputersโ, NOT โMy Driveโ or Shared Drives)
- Renaming files
- Overwriting files
Note: sometimes syncing file changes might take a while and in the meantime you may see the wrong date. In order to properly test this I recommend waiting enough time for the synchronization to go through. And bear in mind that even if the Drive sync client is not showing any ongoing activity there may still be some processes being carried out by the Google Drive API or scanning for malicious content. So be patient before jumping to conclusions. And always refresh windows (on the File Explorer too). And letโs not forget the basics: if needed, restart your computer, restart your Explorer.exe (or Finder, on a Mac), restart your browser, and, last but not least, the good old โclearing cache and cookiesโ.
The results below apply to non-Google files created locally and uploaded, synced or copied to Google Drive
Notes:
UNDO after renaming or overwriting a file does NOT bring the original date back.
A local UNDO (using the File Explorer) after overwriting a file will not restore the previous version. Instead, it will send the file to the trash (with any revisions it may have). This behavior is consistent with what Windows does with local files when performing and UNDO after overwriting them.
Conclusions:
- The first time a file is created there is no issue at all, as in every scenario the original date (of the last modification) is preserved
- After renaming a file, on the Google Drive Web Interface the Date is always wrong, but if the same file is viewed using the File Explorer the correct date is preserved in several scenarios.
- Overwriting a file results almost always in seeing the wrong date on the web interface. The only exception is with the second scenario (using local File Explorer + Drive sync app to sync a local folder to โComputersโ).
- For the first scenario (using local File Explorer + Drive sync app to sync to โMy Driveโ or a Shared Drive), if users work consistently with the local File Explorer they can enjoy a mostly issue-free workflow. There is a cosmetic issue that is only visible on the web interface, after renaming a file, but if the user checks the same file using the local File Explorer the โModified dateโ is correctly preserved.
- The second scenario is useful for users that donโt care about file revision but do care about seeing the correct Modified date when viewing files on the web interface of Google Drive, since it is the only scenario that allows the original Modified date to be visible on the web interface. However, this is only true if the files were overwritten using the local File Explorer. This scenario also allows the creation of file revisions but for that the web interface will have to be used and in that case the Modified date will not be correct (when viewing that file on the web interface). In any case it gives users the choice.
- The third scenario is useful for users that donโt rely on Modified dates to organize files (or their workflows) and want to have file revisions automatically created, and/or prefer to work mostly using the web interface or have a mixed workflow (working with files both locally, using the File Explorer, and on the web interface).
- The fourth scenario is a slight downgrade from the second scenario, but it might be appealing for users that like the second scenario but prefer to have a workflow that mixes local and web-based file operations.
Recommendations:
- Admins should choose a workflow and try to stick with it. And train end-users to avoid issues and/or to understand why issues may occur and the available workarounds.
- My personal recommendation is that features, practicability, and real-life improvisation should be balanced, so Iโd go with the first scenario when possible and use the second scenario when needed (like when using a shared computer or a Chromebook), but knowing the consequences of overwriting files for the modified dates. And Iโd use the other scenarios for different purposes, such as keeping local folders from different computers in sync with Google Drive. This is especially useful for users that work from several computers (otherwise, for users with only one computer, itโs simply a backup of a local folder).
I really hope this helps.
PS: For better readability, you can also check the following Google Doc: https://docs.google.com/document/d/1-exrq_MkptQpJRK7ZgJm4JuoaDM6u8kaQ-9_OuOVg7Y/edit?usp=sharing
Thanks for this detailed testing summary.
Out of curiosity, how much time is enough time?
On my side I have done another round of checks and found somethings interesting:
(The original file was first created in 2015, even though it is a 2008 document)
1. On web the date is still correct (2015)
2. On PC1 (used for copying the file from a local NAS samba shared drive to Windows Google Drive Explorer), the date is wrong (2022)
3. On PC2 used to see the same files locally on another PC, the date is correct (2015)
So this seems to indicate that the overall process is good and the original creation date seem to be kept in Cloud and in other clients, except that the date displayed date on the local computer that was used to manually copy the files is wrong.
Not sure if this resonate with your findings, because apparently you don't have this issue, when you said the Date Modified is Correct?
