I’m not fiercely hating snaps—I’m only annoyed by them. A lot, but once they’re there, and Canonical doesn’t seem to give up (snaps won’t share the fate of upstart, Mir, and Unity), Ubuntu will be plagued by snaps like forever.

But I always love reading The Reg, especially readers’ comments. Here’s one such instance that brought me joy: VS Code for Linux may be secretly hoarding trashed files: Versions installed via Snap don’t delete files when users empty system trash.

Linux users who installed Microsoft’s Visual Studio Code as a Snap package may want to check to see whether files they sent to the trash with the app have actually been deleted.

A handful of Linux-based developers have found large amounts of supposedly deleted data on their computers, in some cases consuming hundreds of gigabytes of storage.

The reason for this is Snap – a Linux application packaging format – creates a local Trash folder for each VS Code version, one that’s separate from the system-managed Trash, according to a VS Code bug report dating back to November 11, 2024.

Not only that, but Snap keeps older versions of VS Code after updates, potentially multiplying the number of local Trash folders and the trashed-but-not-deleted files therein. Emptying the system Trash folder doesn’t affect the local instances.

Neither VS Code nor Snap offers a way to manage these local trash folders, though this can be achieved with the command line.

The root cause of the mess, according to a Microsoft engineer, is an unfixed VSCode change from October 11, 2024, that sets the XDG_DATA_HOME environment variable equal to $SNAP_USER_DATA/.local/share.

“This creates a bogus Trash that’s not the system one, and as such is unmanageable (and is carried over from update to update, gradually inflating),” the bug report explains.

…

Robotics engineer Iván López Broceño reports finding almost 200 GB of files that he believed he deleted.

Web developer Chris Hayes said in the discussion thread that he found 44 GB of files in Snap’s local Trash folder dating back two years.

Asked whether it’s unusual for a bug like this to linger unfixed for more than a year, Hayes via email replied, “I’d say this is unusual when the risk is that the user can totally run out of space on their machine. In fact, that’s how I first discovered it. I was running out of space, I pulled open Ubuntu’s ‘Disk Usage’ and was pretty confused by how much space the VS Code snap was using.”

Hayes, however, said he could understand how a bug like this might get lost in a massive repo like VS Code, which has 12,000+ open issues.

Joy, happiness, ecstasy!

As usual, the comments section is worth reading (if you’re a h8er like I am):

Snap

Needs to die.

That is all.

Re: Snap

So does VS Code.

Re: Snap

Indeed. Why anyone uses either is beyond me.

We really need to start teaching kids how computers really work, before it’s too late.

Re: Snap

Joined the local HS robotics team this year to help them out. Guess what First promotes for programming. VS Code. Terrible.

Re: Snap

And take flatpack with it. Or whatever idiocy ‘let’s create a VM for each and every application’ comes next.

Re: Snap

I don’t like Flatpak either, but at least it has the decency of actually being FOSS and not a trojan horse malware hijacking the Chromium distribution.

Re: Snap

Erm… flatpack is not creating “a VM” though… just namespaces and cgroups? the only difference is that they link statically everything to create complete “app bundle” (similar to applications on macOS) that works the same on all distributions…

Re: Snap

And if the creator of said flatpack bundle decides he likes a pink theme, you’re stuck with it, regardless of your default one. Just an example, mind you.

Re: Snap

OK, container. Are you happy now?

Re: Snap

“Or whatever idiocy”

This. Oh so much this.

I have installed a little app that uses Python to act as a front end to the configuration of my Livebox (Orange France bundled router).

Because it is Python, it has set up one of those virtual thingummies…..which now contains over 700MB of libraries and crap.

And I’m not smart enough (I’m a Linux newbie) to say “just use what’s installed normally” to see if anything goes wrong or if it works.

Re: Snap

Maybe it does for many other reasons, but in this case isn’t the bug that the package “sets the XDG_DATA_HOME environment variable equal to $SNAP_USER_DATA/.local/share.”?

I’d not lay that one on Snap itself, but the package. Unless I’ve misunderstood.

Re: Snap

It sounds like a bit of both. It sounds as if Snap is creating a new $SNAP_USER_DATA for each update to VSCode. It’s not necessarily a s trash problem because whatever else gets written in there is abandoned on every update so even without the trash directory being in there it’s going to keep filling the drive, just more slowly.

Simple

Copilot, fix all the VS Code issues.

Re: Simple

# rm -rf /

Done!

Re: Simple

Won’t work, you’ve commented it out.

Typical AI slop.

Re: Simple

Hmmm…

More likely AC means you’re issuing the command from a root shell?

Re: Simple

I think mister trollface there suggests this misunderstanding is intentional.

SOP: remove flatpak, snap, pulseaudio, pipewire..

If the desktop dies, it didn’t deserve to live.

In fact the dependency of modern Linux desktops on all this is now do chronic that I am using in beta, Ubuntu (or Devuan) Server, fluxbox and tint2.

It’s kinda nice: I use tint2 to display all my favourite apps (on a top bar) and customize the fluxbox config file so a right mouse click lists my last used apps.

Very easy to navigate… I hate menus hence my current use of Zorin (with the mobile skin) but Zorin 18 now has a dependency on pipewire so removing it kills Zorin.

Re: SOP: remove flatpak, snap, pulseaudio, pipewire..

I’d like to use PipeWire/PulseAudio…but on my machine it usually keels over dead after a few minutes (not a peep in dmesg), leaving me to use a standalone Bluetooth speaker. A recent kernel fix (Mint Cinnamon) caused it to die immediately, and a more recent kernel fix reverted that so now it is back to waiting for a little while before dying.

And I’m left wondering what the hell a driver for a decade-old Intel audio chip is even doing in the kernel in the first place.

I don’t go near Flatpak because the package manager has some ridiculous size, like 3.9 GB or something, for all the packed software. Maybe that’s worst case scenario, but it’s not particularly helpful.

Containers. What’s the fucking point.

“Use Docker” they said. “It’ll protect you from OS updates”.

I used Docker.

I ran a lovely container that run my PAN newsreader in a container freezing it in a known good state.

Come Debian 12->13 and guess what. Changes to Docker broke the container. Because apparently changing a host library can cause Docker to have to use it and if breaks the underlying container … well, guess who has to download the source into the container and recompile in a hilarious Saturday afternoon.

Apparently I am the odd one for expecting containers to survive OS updates and upgrades.

(The magic Google is “Debian 12->13 Changes to Docker broke the container”)

I find SNAP a nightmare

I find SNAP a nightmare and have stopped using it.

Files you might want to backup are scattered all over the place whilst files which should have gone are still scattered.

Re: I find SNAP a nightmare

I have run out of disk space ‘uninstalling’ snap packages. I don’t care that it thinks CoW is the ‘right thing’, it should not poop itself under these conditions.

Ah, the orgasmic joy of modern computing. BTW, VS Code offers repos for most major distros.