Adobe CC Bug Erases Data on Macs (UPDATED)

A bug in a recent Adobe Creative Cloud update is currently deleting a folder on the root drive (Macintosh HD, by default) of Macs upon installation. This issue is affecting Backblaze users disproportionately due to the fact that the bug results in the deletion of the contents of the alphabetically first hidden folder on the root drive, which is often the folder ".bzbol" for Backblaze users.

Of course, if you are not a Backblaze user, the bug can still delete files within whichever hidden folder in your directory is first alphabetically, which may or may not have extremely undesirable consequences on your system. For some readers, the first hidden folder may be one called, ".DocumentRevisions-V100," the files within which are necessary for proper file version mapping and recovery functions within OS X. Whether or not there may be a solution that undoes the deletion (or rather, replaces these files) is still unclear. Adobe said they have stopped distribution of the update that causes this issue, which began with version

Backblaze posted a video (above) showing the deletion of the files, but also shared a temporary solution, which naturally involves creating a hidden folder in the root directory that comes before the one called ".bzvol". They have managed to fit a small bit of humor into their fix, but they undoubtedly find little of this situation funny, given the impact it's had on their users.

Temporary fix:

To correct this, please do the following:

Open Terminal, which is found in Utilities under your Application folder.

Copy and paste the below command, pressing enter after:

  • sudo mkdir /.adobedontdeletemybzvol

After you press enter, you will need to enter your Mac Admin password and hit enter to create the folder. 

This should protect your .bzvol folder from being emptied by Adobe Creative Cloud, as the new folder is now first alphabetically. 


**If the bzvol folder has already been wiped, you will also have to follow these steps after creating the new directory.**

1. Click the Backblaze icon and go to preferences.

2. Click the Settings button.

3. Check both boxes for the unplugged and plugged in internal Mac HDs. 

4. You may receive a message that one drive will replace the other -- this will not affect your backup with this issue.

5. Click OK

This should resolve the bzvol error and allow backups to resume, as scheduled. 


**If you have any hidden folders alphabetically before .bzvol, you may want to restore them from Backblaze.**

The latest 'beta' installer of the Backblaze software has been updated to create a folder named '/.aBackblaze/ at the root of your hard drive as a decoy folder. Running the latest installer will also prevent this issue, like following the above steps. The installer can be downloaded here:


[via ArsTechnica]


UPDATE: Apparently, Adobe has resolved the issue with a new CC release. Of course, this will not fix or reverse the deletion issues in any way. The new version will not, however, cause the issues to begin with for those that are lucky to not have been affected.

Log in or register to post comments


Alex Kane's picture

Oh, that's what happened? I got this error and did the "click both hard drives" thing, but I had no idea this was caused by CC. Thanks, Adobe.

Daniel Wesser's picture

For anyone not using Blackblaze who wants to create a sacrificial hidden folder:

Go to the root directory of your boot drive (MacintoshHD by default) and create a folder named ".aaa_delete_me" without the quotes. You will need an admin password for this.

To confirm that the folder is the first alphabetically you can view hidden files by opening Terminal and typing "defaults write AppleShowAllFiles YES" without quotation marks and hitting return. Then type "killall Finder" (again without quotation marks and hitting return).

To re-hide hidden files use "defaults write AppleShowAllFiles NO" followed by "killall Finder"

Note that if you have hidden file selected when you type "killall Finder" Finder will reopen with that file still visible until the window it was selected in window is closed.

Brad M's picture

If you are on a command line anyway, you can use the command "ls -al" to show hidden files - all letters are lowercase. The 'a' flag is 'show all', the 'l' flag shows the files in a list. This is a lot easier than changing your defaults and restarting your finder.

So the commands that Backblaze recommends are--
cd /
--- This changes you to the root of your file system, or, the / directory. Not really needed, but it doesn't hurt.
sudo mkdir /.aaaaaaa
--- this will make a sacrificial hidden folder that is likely alphabetically first. It will also require your user's password, and for your account to be an admin.

If you run "cd /" first, the second command can be "sudo mkdir .aaaaaaa".

However, this is someone on the internet telling you to run a sudo command, which in general, can be a very bad thing to do. So, use your best judgement.

in a file listing, uppercase characters will list before lowercase. So will numbers. If you really want to be paranoid, mkdir /.0000000000 would be safer.

barry munsterteiger's picture

yeah... this totally borked my entire projects folder as I use " projects" with a SPACE before the folder name so it appears first at my root directory level. WTF adobe.... luckily I have a Time Machine backup because there was over 200GB of files in that projects folder.

Just a word to the wise: putting an "_" (underscore) or muliple "___" if need be is FAR preferable to spaces on a UNIX system. If you ever need to do some some strict terminal recovery, you'll need to "escape" the spaces, which just adds more work and potential for errors. Just saying.

dred lew's picture

As protective as Apple sometimes may be, especially when it comes to the file system on iOS, they unfortunately have failed to implement the same "tampering" protections on Mac OS. Windows actually handles that better by hiding any system files by default. However, Mac OS being a full fledged UNIX system (with some sugar coating on top), the average layman should have no business being in any folder other than his user folder. - Meaning, Barry Munsterteiger, your personal files ONLY belong into your user folder, into one of the designated folders like "Documents" or "Photos". That way you are not interfering with the underlying technology of the system. It will also help you transfer files with the "Migration Assistant", should you ever need to.

stir photos's picture

Not trying to troll here, just wanna clarify that rights to directories/folders aren't managed by their state of hidden on or off. So, we could recreate this defect if a directory/folder was hidden or not hidden. I'm pretty sure (not 100%) the folder(s) mentioned in this article are hidden, and it's not a user putting files in folders willy nilly; rather, it's a 3rd party script that wrote against the directory/folder (hidden or not). And one last thing... folders/directories are not the "underlying technology of the system", that would be the Kernel. :)

dred lew's picture

My comment was in regards to him having a project folder at root level, where it does not belong in the first place. None of his files would have been affected by the bug if he had stuck to his user folder. He had a backup though, so that's a plus.

To clarify, by "underlying technology of the system" I'm referring to the way Apple designed its UNIX, which is quite different from any other UNIX available. Again, the design could use improvement, the average user does not need to see anything other than his user folder in order to not tamper with the system. The fact that the default user is always an admin makes the access control fairly ineffective.

barry munsterteiger's picture

This is where the "right" way to do it from an engineering standpoint and the "right" way to do it from a consumer are very very different and Apple has always been different in how it thinks. In the 16+ years of running OSX, an early adopter of nearly everything, a former employee at Apple, and being well organized it was immediately perceived as something I had done. It wasn't until I read the article that I even imagined it was something that had been installed by a 3rd party messing with things in a directory they had no need to touch.

Regardless of what the UNIX community believes is right or wrong, it's my machine and if I can create a folder somewhere I will. Having multiple users on a system that protect directories that are used across them is exactly what the root level is for and this allows my machine to see the same directory from multiple logins. sure there are probably other ways the UNIX admin/engineers would have done this but I am not one.

It is unfortunate when things like this happen, having backups is the only way to protect from the unexpected. I learned this the hard way very early in my computer life when a RAID unexpectedly dropped a drive from the array.

Its more unfortunate that nasty "bugs" like this exist, seems more like a disgruntled engineer wrote something malicious to see what would happen. (yes that is highly speculative but not out of the realm of possibilities)

dred lew's picture

Nope, the root level is for the system. Your personal files belong into the user folder for protection and yes, there is also a "Shared" user to share files across multiple users. UNIX is by design a multi-user system. The root level has a certain structure and you should not mess with it. You see what can happen. Not that this should have happened but it's a good example of why you don't touch the system, especially not to randomly store files.

Maybe as a desktop analogy that the OS is built upon; say you are working in the office, you don't just throw your project files onto the boss' desk. You store them in/on your own desk. - Just because you can, does not mean you should.

I'd worked for Apple and support centers for years, dealing directly with end users who messed up their systems in all kinds of ways. Again, my advice is, stick to folders (Users) you are meant to use and don't touch the system. This isn't coming from some UNIX purist but from a seasoned Apple tech.

stir photos's picture

Hi Barry,

I'm not on a side here, but if a gun was to my head and I had to pick though, I'd pick yours because I get where you're coming from. I also get where dred is coming from [absolutely], but he's stuck in some strange dogmatic point of view that's deeper than I care to visit... Although he has a point that I get, I fear he's somewhat horse blinded and not really seeing the big picture.

Letter of the law for best practices; yes, his point makes sense about "not saving files to root", blah blah blah.... Jesus Christ, he might've just as well added "thou shall not..." in there for some added effect. However, in the spirit of the law of best practices, you are absolutely correct.

The short story is that you [indeed] have the perfect right and sensibility to create folders/directories with any name you see fit. Sure, there are best practices out there, but they're not an absolute rule in this situation. Are you within your reasonable head space to be pissed? Fuck an A yes you are...

However, having an understanding of both sides, just below is a brief outline of some clarifications and my thoughts:

barry - "... that had been installed by a 3rd party messing with things in a directory they had no need to touch. ..." Nothing was installed, it was a script stored outside your machine that modified a folder on your machine one time. You're right, there wasn't a need to alter either folder (your created folder OR a default folder already in place) by CC (the 3rd party).

barry - "Having multiple users on a system that protect directories that are used across them is exactly what the root level is for..." Actually, multiple users is a feature. The root directory/folder's purpose is to boot the mounted file system(s). Any file that happens to be saved in the root folder/directory that doesn't belong in the boot process is just ignored (not ignored literally; remember, letter and spirit of the law). Basically, "multiple users" came along later, so that feature has carried over, as many features do in different OSs.

dred - I'm pretty sure everybody gets that you shouldn't save files in root. If not, they should after reading this.... BUT, from what I read, you're missing the point and you're missing the idea of "root" in both the initial article and some of the responses. First, it seems like you should at least know that "root" can be sort of confusing when it comes to Unix. If I'm wrong, sorry, but basically saying that A) a user CAN'T make a folder with any name (s)he wants to isn't correct. B) This goes for limiting users to where they can save their files, as well. Yes, there are best practices; no, not everybody knows them or cares about them; no, a folder/directory above the " /" doesn't make it "the root folder." It also seems like you should understand that Unix's "root" concept (omg, don't get me started on your "sugar coating" version), let's just stick to the idea that Unix's concept is sort of confusing (by those with less in the know maybe) by allowing a directory in the tree to come before the actual system root folder; again, without it actually being "the root" folder that you seemingly keep pointing out. Windows, by comparison, doesn't allow this since a mounted volume (which also happens to be it's root directory) is designated with a letter, eg: "C:", and nothing can be above that in either the literal or virtual respect. Okay, unless you're talking about multiple mounts on a much larger scale, but "spirit of the law" here. Even another poster here commented the same idea about using underscores or even double underscores in favor of blank spaces in file names for it's potential ease of use and clarity's sake, but he didn't say it was against any hard rule or imply that it was somehow the user's fault. This is not the user's fault.

dred - "None of his files would have been affected by the bug if he had stuck to his user folder...." This bug could've just as easily happened to ANY folder given the circumstances of how the bug was written. Letter of the law; sure, in this incident you're right, but that same comment is dead wrong if we could reenact the bug with a more targeted folder name along with a similar outcome/ending. Why not?

dred - In other words, if a senior executive at Apple named a local folder " a importantFolder" and it's contents were deleted permanently, you would tell him/her that it was their fault, and "Your personal files belong into the user folder for protection." LOL, C'mon man, maybe I've been in the corporate world too long, but even I'm not that jaded with the game.

Anonymous's picture

And just another reason why I never upgrade when it comes to Adobe..

Joakim Drake's picture

So, basically Adobe CC is now a virus?

Leif Sikorski's picture

Not trying to start another Mac vs Windows discussion (and please don't make one out of this post) - when it comes down to things like audio routing I'm jealous of the Mac users and each platform has it's own benefits.
But for some reason the whole Adobe Software seems to make much more problems on Macs than Windows. It starts with the GPU support that is more problematic on Macs and ends at such little bugs that are often just Mac only related. The issues it first had with El Capitan is another example.
I get the feeling that the relationship between Adobe and Apple is not as good as they sometimes pretend on the stages. I doubt that it's just Adobes fault - they both need to work on it because such things just shouldn't happen when they aim at professional users.

"...I'm jealous of the Mac users...", nah I doubt it. Why, the meaning of jealous is feeling or showing suspicion of someone's unfaithfulness in a relationship. Envious would be the correct word.

Aleksey Leonov's picture

My be we have to start lawsuits, in other case Adobe free to do what ever they want. We are not beta testers! I believe many people lost files, that leads to money lose.

Adam Ottke's picture

I'm sure Adobe protects themselves in their user agreement. In addition, while it's extremely frustrating and silly that a product this popular and from such an established brand has issues like this, people should KNOW to have constant backups going 24/7 with local snapshots. The software is there and included/free for pretty much any computer you have, and there's simply no excuse to not be backed up.

So realistically, as scary as it is, at worst it should only hurt you in taking up a little extra of your time. Again, I'm not trying to minimize the scariness of stuff like this happening. There's no doubt Adobe's reputation is hurting from this -- and rightly so. But at the end of the day, it's pretty typical "shit hit the fan" stuff that we can and should be able to deal with.

Eric Mazzone's picture

Those sorts of waivers aren't worth the electrons used to display them. For something THIS major, they will be full of liability. I'm thinking this is why my Time Machine disk took a dump on me the past week, wiping out two other partitions on that disk. Freaking Adobe.

Joakim Drake's picture

I agree, this software has no business deleting files it doesn't create itself. Its behaviour is that of a virus.

While I also agree with Adam Ottke that backup should be second nature to any professional, one shouldn't be worried it starts deleting system files all of a sudden. I wonder if this is a bug, or malicious intent from one of their software developers.

Eric Mazzone's picture

I consider this malicious since it borked my BACKUP! Adobe better figure out some way to fix their damage to my system! They have no choice in this matter other than to restore it back to where it was before THEY screwed it up!

Eric Lefebvre's picture


Liability waivers aren't as iron clad as companies would like us to believe. In most jurisdictions a well written waiver protects against "ordinary negligence" but not against "gross negligence".

Here is an example.

You go to a gym, you are on the treadmill and break your leg because the thread mill suddenly breaks and stops working. If all maintenance schedules were followed and the machine had not been reported as defective before hand, that would be considered "ordinary negligence" and a well written waiver would protect against this.

If, on the other hand the machine had had several reports of poor operation and no action would have been taken then that would potentially be considered "gross negligence" and no waiver, no matter how well written, would protect against that.

It's the same situation with non compete clauses in employment contracts ... the contract can state whatever the employer wants but that doesn't mean the clause is legally binding. Non compete clauses get thrown out of court ALL THE TIME because they are too far reaching or too restrictive.

In photography, for example, I have a waiver in my contracts that state I am not liable if my gear dies, memory cards cirrupt ... things that out of my control but if I am completely stupid and leave all me gear in the car over night and have all my shoots for the past 2 years stolen because I didn't do a single backup (something that any professional would/should do) then that is GROSS negligence and my contract won;t protect me against that.

I'm refrencing this article btw:

This is the PERFECT example of gross negligence in photography.

But back to Adobee deleting your files ... it would be far more difficult for you to prove gross negligence compared to ordinary negligence ... in programming it's not as clear cut as proper maintenance schedules or established standard workflows (ie.: backups) and the likes.

Eric Mazzone's picture

They borked my backup, that is negligence in their part!

Eric Lefebvre's picture

To start, I'm not a lawyer.

I agree with you but the question is, is it GROSS negligence or ORDINARY negligence.

Did the bug slip through because they didn't do proper testing or did they do adequate testing but for some reason or another they were not affected by this bug.

The first example is gross negligence the other is ordinary negligence.

Like I said, it' much easier to prove gross negligence in other fields like food service or professional photography.

Didn't follow standard practices in terms of food prep (cross contanimation)

Preventable loss of clients images due to not doing proper redundant backups.

How do you prove GROSS negligence in coding? That's what I was trying to explain.

william mitchell's picture

Glad I am not using CC, how could a bug (virus) like this be created? Should the OS alert the user about this ? Customers should not be Alpha testers.

Adam Ottke's picture

The OS doesn't alert users because technically speaking, the installation program from Adobe has permission to do whatever it needs to (it needs that permission to place files that are part of the installation process), so Adobe's program can do what it wants/needs to during installation. And in this case, for whatever reason, it "wants" to delete the files in that first hidden some point...

Eric Mazzone's picture

Another non-coder who doesn't understand OS's.

stir photos's picture

Great informative post. If it helps, I read the article here:

Just FYI for some of the poster's comments/questions: It's not a virus, it's a defect in a script from CC. The OS wouldn't have a way to detect a buggy script, the OS's defense is mainly preventative that asks the user for an Admin password to install an update from a trusted source, or to install software initially whichever is the case (or both). and an LOL to the comment that we shouldn't be beta testers, right!? In this case, we'll just cross our virtual fingers and hope that Adobe takes this mulligan as an opportunity to add this incident to the management of their Unit testing. Oh Adobe, you're so cray cray...

Dan Ostergren's picture

I just updated CC. Do I have to be worrying about my projects being deleted now if I don't use Backblaze?

Tlamati Xochipilli's picture

On the same boat as you. Don't use Backblaze but wondering if there is anything I should worry about it? Would hate as much as anyone else if *any* data was lost. What the opinion 'round here?

More comments