Google Drive users complain of missing files, months of data disappearing
Cloud storage service Google Drive is losing user files, and engineers warn users to avoid making changes or troubleshooting while the issue is investigated and resolved.
Missing files on Google Drive
Cloud storage solutions like iCloud or Google Drive allow users to access files from anywhere but are far from perfect systems. As with any data container, users must keep data backups to prevent accidental data loss.
Some users are learning this the hard way, as Google Drive seems to have dumped random amounts of data for some users. According to a report from Android Police, multiple users have taken to forums to share similar missing file issues with Google Drive.
The earliest report of missing files on Google Drive comes from a South Korean user. On November 21, the user shared that its Google Drive account reverted to a file structure from May 2023, losing all new files and changes that occurred since.
A Google Drive employee replied to the thread on November 27, sharing that the team is "investigating reports of an issue impacting a limited subset of Drive for desktop users and will follow up with more updates."
The team member urges users not to click "Disconnect account" within the Drive for desktop app. Users should also avoid deleting or moving the app data folder.
The app data folder is in the following file locations:
- On Windows: %USERPROFILE%\AppData\Local\Google\DriveFS
- On macOS: ~/Library/Application Support/Google/DriveFS
The Google Drive team member also recommends users create a copy of the app data folder if possible.
While initial reports didn't specify where issues arose, either in the mobile app, on the web, or the desktop, the Google Drive team member clarified the issue. It seems to affect only a limited number of desktop app users, like those on macOS or Windows.
As was recommended, avoid editing or changing files in the application folder or signing out of the app. A fix will likely be found and issued through a future update.
Also, remember, when it comes to files, one copy is none, and two copies are just one. Backups are essential in preventing issues like these with Google Drive from complete data loss.
Read on AppleInsider
Comments
Does it? Been using it since inception for all my files and haven't lost a single byte.
Found the following warning, but may not be related: "If you're over your storage quota for 2 years, your content across Gmail, Drive, and Photos may be deleted."
Wondering if Google Cloud sets a file expiration date? Problem sounds vaguely similar to problems on several OS's, but those probably were 40 to 50 years ago, and I cannot remember what caused the issue. Suppose it could also be due to triggering some kind or roll-back of a journal or reversion to an older incremental backup (by Google, assuming they do whole disk image backups). If they mirror disks. maybe one of the drives failed and the other mirrored drive had not received updates for months. Then, when the up to date drive failed, data was rebuilt from the out of date mirrored disk.
Bet Google will be examining any code changes on their side, followed by any code changes on the client side. Also, any code changes by equipment vendors (bet there are many layers to investigate).
You're likely thinking about Y2K where years were often stored as 2 digits, so "88" could be 1888, 1988, or 2088. Some computers struggled with that as Year 2000 approached.
I worked on Y2K, primarily with IBM manufacturing software that usually coded dates (mostly on DASD) with a three digit year. "088" was normally converted to 1988, "188" would be 2088, "288" would be 2188, and so forth. Sometimes, transaction dates (normally transactions are discarded after 7-10 years), were stored as two bytes with a sliding range, with 50-99 being 1950-1999, and 00-49 being 2000-2049. Birthdate would be better converted to a 4 digit year or a timestamp. There were also timestamp dates that were binary based on 0 being a reference date and time (fairly common in Unix and some other OS's). I remember several airports with a Microsoft application displayed January 1, 3000 instead of 2000 at the strike of midnight. Almost all OS's will have another Y2K-like issue in the future (requiring a mass-change to timestamps or other storage methods). I cannot remember off the top of my head the maximum (normal) storage date for Oracle, Windows or macOS (this has changed over the years, and there may be multiple types of timestamps). I bet for large data sets that have never been converted (in any application), there are issues lurking in the future).
Found this from the Oracle help center:
"With the fractional part included, the format for these values is ' YYYY-MM-DD hh:mm:ss [. fraction ]' , the range for DATETIME values is '1000-01-01 00:00:00.000000' to '9999-12-31 23:59:59.499999' , and the range for TIMESTAMP values is '1970-01-01 00:00:01.000000' to '2038-01-19 03:14:07.499999' ."