Protection from Adobe Creative Cloud Bug | Hacker News Reader

Protection from Adobe Creative Cloud Bug

alanwsmith.com

63 pointsalanwsmith32 comments

"Software development is hard. Adobe's software is incredibly complex. Sure this sucks, but it's worth keeping that in mind before blasting Adobe."

The sentiment is solid, but this is a major software company dropping an update that fails to do BASIC checks (like "is the target directory named what I expect?") before permanently deleting data. Blasting is entirely appropriate.

Especially for a company like adobe that doesn't exactly have the best track-record for solid software updates....

Totally agree, but as you pointed out Adobe is a Tech company. It has the dollars to do full development, to hire good people, and do things right.

Software development is hard, managing projects and making stupid decisions is easy.

This is worse than the other serious bug I've been dealing with today in Lightroom.

TL/DR, using Lightroom's import function creates huge amounts of crap video cache files in at least two buried directories regardless if those video files are imported into LR or not. I had a 5-6 GB photo library and 262GB of cache files for video I had not imported. The application has a cache limit, and blew by mine by a factor of 87. Cache purging does not delete the data either.

Anyway, not releated to this particular bug, but I'm not feeling much love for Adobe today.

https://feedback.photoshop.com/photoshop_family/topics/light...?

Oh my god, I didn't notice this until you mentioned it. The lightroom cache contained a full copy of every video file on my hard drive - over 250GB.

Got ya beat. LR had multiple cache files of all my video files. I have multiple point in time backups of my key data. I also have a fracked up photo library due to a pre-CrashPlan operator error that deleted some important pictures. So I've been running the import process over these point in time back ups to restore. So my cache file directory looked like this:

Stupid_video_cache_in_Lightroom.whatever Stupid_video_cache_in_Lightroom_(1).whatever Stupid_video_cache_in_Lightroom_(2).whatever Stupid_video_cache_in_Lightroom_(3).whatever Stupid_video_cache_in_Lightroom_(n).whatever

Kill me now...

Where are these buried cache files? I need to check this out, and I'd like to either find them or be sure I don't have them.

Depends on your OS. Mac OS X, check:

/Users/username/Library/Application Support/Adobe/Common/Media Cache Files /Users/username/Library/Caches/Adobe/Lightroom/Video/Media Cache Files

Windows, you'll have to trawl this thread for probable locations:

https://feedback.photoshop.com/photoshop_family/topics/light...

"Software development is hard. Adobe's software is incredibly complex. Sure this sucks, but it's worth keeping that in mind before blasting Adobe."

That's a joke, right? Software development is hard, but this kind of mistake is indefensible.

Even just trying to figure out how this bug could even be introduced baffles me, and I've been able to correctly determine the cause of some very odd bugs before (including this one from Adobe: https://news.ycombinator.com/item?id=8797640 )

It reminds me of this quote:

"There are two ways to develop software: Make it so simple that there are obviously no bugs, or so complex that there are no obvious bugs." - Tony Hoare

Not in today's Agile world.

Really the problem is just there wasn't a user story saying:

  As a user having a directory .AAAAA 
  When I run an Adobe application 
  The directory should still be there

Also, the computer should not spontaneously combust. And it shouldn't try to bite my hand off. And it shouldn't morph into a soul-devouring monstrosity either. In other words, there is an infinite list of things that your/my/any program shouldn't cause. Good luck making user stories for all of them.

This so much.

If your Agile developers follow user stories to the exclusion of common sense, you should probably fire them now.

I'm fairly certain the parent post was made in jest.

Me too; hence the absurd examples :)

Sounds funny, but you are sadly correct. Some junior (or even an experienced) dev just took the shortest route to delete the file that was always listed first on their computer. `deleteFile(files[0]);`

My favorite latest CC bug: There's a node.js instance that CC installs that constantly pegs my CPU at 50%(100% core 1 of 2).

I can kill it and it keeps coming back, Freaking annoying, I'm almost to the point of just uninstalling CC from my laptop and leaving it only for my desktop.

No clue what it's doing there but it'll happily spin away for hours at 100% utilization.

Is there a way to throttle it without killing it?

could you suspend the process with e.g.

kill -SIGSTOP or kill -SIGTSTP

I wish Adobe upgraded Node to the LTS at least; last I checked, they still used Node 0.10.

"Good news, everybody. Further reports indicate the bug doesn't delete the folder, just the contents. So, all that needs to be done is to make a protection folder one time."

Oh great! I'm glad it just deleted the files but leaves an empty folder intact. Really dodged a bullet there.

In the original post, he says that you need to create a directory, and then write a script to recreate it in the event that it gets deleted (to prevent Adobe from nuking your files). Since Adobe deletes the contents and not the folder, it turns out that you don't need to keep recreating it.

Yev from Backblaze here -> Today was a weird day.

Some poor programmer is going to get it after the source of the bug is git blamed... (Well, Perforce blamed? Does Adobe still use Perforce?)

Their QA dept should also get it.

People make mistakes during development... but there's no way this should have gotten past even basic QA testing. :(

Q...A?

It sounds like you want those to be steps that come after each other, like some sort of waterfall.

If you want to get with the times, you, the developer, should write a unit test for each file you think shouldn't be deleted on running the application.

Heh Heh Heh

That's one way of looking at it. ;)

Another way of looking at it is there shouldn't be a product update/release getting pushed out to hundreds of thousands of users (a guess), without passing an extensive validation suite. Developer unit tests are for a different purpose.

Unless I missed your sarcasm? :)

> Unless I missed your sarcasm?

Ohh yes.

Nowadays I work in medical devices. It's nice because you're actually legally required to spend 5 minutes making sure your product does what you say it will before you're allowed to sell it, in contrast with what's happened to the rest of the industry.

I wonder if an ACL can help.

  # chmod +ai "group:everyone deny delete" folder

Should set inherited deny delete for any user.

For pete's sake can someone, anyone just lead us to details about the bug itself? I don't even know what this is protecting from.

Today my backblaze started complaining that it couldn't find a key folder. This explains where it went...

Full explanation from the Backblaze folks [1].

[1] https://backblaze.zendesk.com/entries/98786348--bzvol-is-mis...

Reply on news.ycombinator.com