Bug in Adobe Creative Cloud updater erases root level Mac data
Adobe has pulled its most recent Creative Cloud update after the version was found to contain an errant script that automatically deletes locally stored Mac user data without warning.
The issue, which presents itself when a user logs into Creative Cloud after installing the flawed 3.5.0.206 update, deletes the contents of the first folder to show up alphabetically in a user's root directory, reports Ars Technica.
According to the publication, customers of data backup service Backblaze were inordinately impacted by the bug, as the company's hidden ".bzvol" root folder is alphabetically first for many Mac users. In the process of troubleshooting user errors, Backblaze confirmed the flaw by creating a hidden folder named ".a," installing Adobe's updater and opening Creative Cloud, a sequence that deleted the root file's contents.
Perhaps more troubling is that many Mac users will find the ".DocumentRevisions-V100" folder at the top their root drive. The file includes data critical to autosave and version history functionality, the deletion of which could result in various system errors.
"We are aware that some customers have experienced this issue and we are investigating in order to resolve the matter as quickly as possible," Adobe said in a statement. "We are stopping the distribution of the update until the issue has been resolved."
In the meantime, Creative Cloud users are advised not to install the version 3.5.0.206 update or, for those who have already done so, not to log in. For users who need immediate access to Creative Cloud, Backblaze suggests creating a sacrificial folder and assigning it a name assured to be first alphabetically.
Adobe has not offered an estimated timeline as to when the update will be fixed and subsequently re-released.
The issue, which presents itself when a user logs into Creative Cloud after installing the flawed 3.5.0.206 update, deletes the contents of the first folder to show up alphabetically in a user's root directory, reports Ars Technica.
According to the publication, customers of data backup service Backblaze were inordinately impacted by the bug, as the company's hidden ".bzvol" root folder is alphabetically first for many Mac users. In the process of troubleshooting user errors, Backblaze confirmed the flaw by creating a hidden folder named ".a," installing Adobe's updater and opening Creative Cloud, a sequence that deleted the root file's contents.
Perhaps more troubling is that many Mac users will find the ".DocumentRevisions-V100" folder at the top their root drive. The file includes data critical to autosave and version history functionality, the deletion of which could result in various system errors.
"We are aware that some customers have experienced this issue and we are investigating in order to resolve the matter as quickly as possible," Adobe said in a statement. "We are stopping the distribution of the update until the issue has been resolved."
In the meantime, Creative Cloud users are advised not to install the version 3.5.0.206 update or, for those who have already done so, not to log in. For users who need immediate access to Creative Cloud, Backblaze suggests creating a sacrificial folder and assigning it a name assured to be first alphabetically.
Adobe has not offered an estimated timeline as to when the update will be fixed and subsequently re-released.
Comments
The iTunes 2.0 installer contained a similar bug, back in the day, that could erase entire hard drives, all because someone forgot to put quote marks around a path variable.
(Not that this excuses Adobe in any way, shape, or form.)
Blame the new kids on the block (complete with MBA's) who are addicted to being online all the time and that all your data belongs to the supplier especially if you were foolish enough to put your stuff in their cloud.
As a soon to retire B-B (born 1953) I refuse to put anything of value in a cloud. When it rains, the clouds go away. none of my peers are cloud fans. You might think that we are Luddites but we value our privacy. Having written my first program in 1972 (puched cards ICL Mainframe), I've been there, done that , got the Bite marks to prove it.
Something should really be done at the OS level to prevent file deletions. Sandboxing like in iOS can be too restrictive but for the odd times that apps would try to remove files outside of their sandbox, the system can ask the user and tell the user what the process is trying to do.
Ideally a system should be separated into 3 parts: [unchanging system software] [system overrides, user software, unix software] [user data]. Right now, they are all mixed together. The core system software should never be modifiable, that's what the overrides are for. The system overrides and software would include system updates so that all system updates could be removed and rolled back to the core system on a bad update. There could be multiple core systems that can be switched out so if you needed to revert back to an older system, you just boot from it and this lets people try out new systems, even beta systems with an easy rollback.
The user data would be completely separate from software so application updates would only write to the software location. By default, software would only have read and create permissions inside user data and overwrites like file saves and file deletions would always require confirmation by the user. To enforce this kind of partitioning might require a new filesystem but this may also allow things like easily setting up a core Bootcamp system, again with multiple versions of Windows or Linux and just allow booting from those and then have a separate Windows/Linux user partition with a different filesystem format. Perhaps there's a way to virtualize filesystem interaction so that the native filesystem is the same but it translates filesystem events on request so that every system can access every user data partition on request.
With the current setup, a single stray command in a script or application code can wipe an entire user's personal data at the user's permission level and if a password is typed in during install, it can do far worse. Software shouldn't be given the opportunity to do damage by default. This won't result in endless permission requests because software would have read and create permissions and overwrite and delete permissions for any files that same process created and deletion events outside a sandbox would happen very rarely, usually only in cases like this where something went wrong.
-kpluck
I do use Dropbox for some data syncing for my nine computers, but I don't put anything sensitive on it.
As a computer consultant I advise people to not put their data on 'another man's computer.' Keep it local and keep multiple copies.