My point here - with my previous post - was to provide some clarification about the available options, not to engage in a dispute of arguments or opinions.
I understand that if someone reaches this page it is because theyโre already facing a similar issue and most likely agree that Google Drive is to blame. Thatโs not my opinion though. But indeed my observations were far from a real-life scenario and were more theoretical.
So, let me take a step back and provide a more realistic overview of this โissueโ.
Letโs imagine this: User A (letโs call him Adam) always uses the web UI and user B (let's call him Brian) uses mostly the local file explorer but also uses the web UI when needed.
Adam is always creating and uploading files to Google Drive and, as he uses the web UI, he sees the dates in which files were created or modified (including when files are renamed, which is indeed a modification of the file, if not of the fileโs content). In his mind, when he has to look for a file he thinks about the date of the last modification, and he understands โmodificationโ as any change made to the file (including its name).
Meanwhile, Brain is creating new files in Microsoft Excel and syncing them up to Google Drive by moving the files to the Google Drive folders or the mounted virtual drive (typically G:). Since each of those files is new to Google Drive they will each get a new file ID and in the first sync Google Drive will query the (local) files metadata to respect the last modification as reflected in the operating systemโs metadata for those files.
Then Brian renames or overwrites the same files and, as he is used to the Windows behavior, he expects the files to keep the previous modification dates (excluding the remaining or overwriting). However, the files are not new to Google Drive anymore, and, therefore, have their own file IDs, which means that Google wonโt have to query the local versions of the files anymore. And so, as any proprietary file system, Google Drive updates the file as it sees fit, in this case, Iโd say, it updates the file based on what Google believes that most people will perceive as the correct option.
This brings us to the real issue here: different people have different opinions on what is the correct modification date.
Knowing this, we must consider what Google is trying to do for a while now, with Google Workspace: change the way we work, by moving from legacy systems and working on Cloud-native environments.
Naturally, this will piss some people off, because they will say that if Google is trying to offer a way to reach interoperability with local file systems then Google should respect the local file systemsโ behaviors. And they are right, to a point. Google arrived later and needs to offer some compatibility features, for sure! But the point here is that Google canโt ignore its own file system and, most importantly, the perception of most of its users, of which the vast majority prefers to use the web UI.
So, hereโs the million dollar question: when Adam and Brian rename or override a file, who is entitled to see the last modified date that each of them considers to be the right one?
- Should Google disregard its efforts to create a new and disruptive, cloud-native way of working to adapt to local file systems?
- Or should Google preserve the work done and do not change what millions of Google Drive users understand to be the correct behavior?
A possible solution for this would be to force the sync client to always use the metadata from the local version of the file, except when the file is changed online (and syncs โdownโ the last modification made on the web UI), but even this would not be flawless, as it would still present the issue of causing conflicting opinions, because while Adam would think that the file was modified yesterday, after asking a colleague to upload the correct version of the file, for example, Brain, on the other hand, would think that the file should show the local modification date.
This can obviously create a lot of debate but the point is that this is ultimately a business decision, not a technical one.
In my opinion, a better solution would be - in addition to preserving the local metadata - to offer to users the option to choose, on the web UI, which modification date to see. For instance: โDate modifiedโ (on the web UI) ,and โSynced modified dateโ
Google Driveโs real fault here is to make users believe (by not warning them of the potential issues) that the sync between local file systems and Google Drive has no limitations. This could also be remedied (or at least greatly improved) by showing a new warning dialog when setting up the sync client for the first time, or, even better, every time a user tries to rename or overwrite a file (and requiring a confirmation).
To finish, I just want to say that this is only my opinion - possibly biased, maybe - and that I really hope not to offend anyone that thinks differently.
LinkedIn
Twitter
