Please move the "$HOME/snap" directory to a less obtrusive location

[John Wang]

Snap package developers should be encouraged to store user data according to the XDG Base Directory Specification [1][2].

I installed the "notes" app via snap on a Xenial desktop:

    sudo snap install notes

and launched it using the snap wrapper script "/snap/bin/notes". The script created a directory "$HOME/snap/notes/1", resulting in the placement of the directory named "snap" directly under my home directory, a situation that is undesirable for two reasons:

- The XDG spec calls for user data to be stored under "$HOME/.local/share" (or rather, that's the specified default when the environment variable XDG_DATA_HOME isn't explicitly set, and default installations of Ubuntu don't appear to set it) .

- It clashes with the directory naming style on my desktop systems. All directories located directly under $HOME that are not prefixed with a dot are named using Capital Case -- e.g. "Desktop", "Documents", "Pictures" -- a scheme which is consistent with the defaults defined in "/etc/xdg/user-dirs.defaults" from package "xdg-user-dirs". A directory under $HOME having an all-lowercase name introduces an ugly stylistic inconsistency and it complicates the navigation of directories in the shell when tab completion is case-sensitive.

Therefore snap packages should base the value of SNAP_USER_DATA on the value of XDG_DATA_HOME (or its specified default). For the "notes" snap, this would be "$HOME/.local/share/snap/notes/1".

If however the XDG spec is considered irrelevant to snap packages, please consider using a proper UNIX-style dot-prefixed directory, "$HOME/.snap".

[1] http://standards.freedesktop.org/basedir-spec/basedir-spec-latest.html
[2] https://wiki.debian.org/XDGBaseDirectorySpecification

Workaround
==========
If you don't want to see the snap folder, create a file named .hidden and in that file, type

snap

You may need to reload your file manager to see the change.

[Launchpad Janitor (janitor)]

Status changed to 'Confirmed' because the bug affects multiple users.

[Stephan Henningsen (zta77)]

This should have higher priority as it really affects everyone using snap.

It is arrogant to think everyone want your ~/snap directory polluting their $HOME! It's cluttering my shell, file browser, everything! I can't even remember the last time I installed an app that pulled this stunt.

Of course this should be changed in accordance with XDG standards. As a minimum this should immediately be changed to ~/.snap. It's an easy fix and is easy to migrate as well.

It's 2017, come on.

[John Wang (johnwang)]

I agree with comment #2 on urgency. Although this issue has been prioritized as "Wishlist" it really must be addressed before snaps are rolled out as a stable production feature of desktop releases, otherwise the practice of storing data under "$HOME/snap" risks becoming effectively entrenched. The longer the practice persists and the more software is adapted as snap packages it becomes increasingly difficult to enact fundamental changes given the general tendency of developers to resist or postpone such changes.

[Zygmunt Krynicki (zyga)]

This is hard to achieve technically and conceptually.

First of all, snapd manages the $HOME/snap directory in non-trivial ways. Some of those include security profiles that carefully spell out the name of that directory or rules that select anything-but that directory.

Snap doesn't what customisations have happened in each users directory. The act of re-locatin the snap directory is non trivial and may include existing bind mounts that cannot be affected by a move/rename operation.

Lastly the directory is not a good fit for .local/share. Notice that while a snap application is running it is observing a $HOME variable set to $HOME/snap/$SNAP_NAME/$SNAP_REVISION. It therefore stores all the typical XDG classes of content (.local/.config/.cache) in that one spot.

[Or Schiro (orschiro)]

It would be great if the user could define the default sub-directory for the "snap" folder.

See also: https://askubuntu.com/questions/885076/how-can-i-change-the-location-of-the-default-snap-folder

[Terry L. Triplett (terry-triplett)]

Zygmunt, that's unfortunate to hear if what you are describing is a fundamental design principle of the snap ecosystem.

While I wouldn't advocate that a user customize their home environment in a way that arbitrarily goes against convention and standards, locations should at least be configurable for when there exists a good reason to do so (and in $HOME, a good reason includes "because that's how I want it"). In this case, the desire is better compliance with an established standard that has become quite popular. That's a good reason, IMO.

What happens under the snap folder is legitimately the business of snap/snapd, but where it's located in the $HOME filesystem should be configurable. If not, it should be placed somewhere that is legitimately manageable by the system and made accessible to users in a way controllable by them (or possibly the system administrator).

As an aside, your description of what basically seem to be "hard coded" paths for mounts and security policies explains a tangentially related problem I'm having with snaps - on my system I use a non-default location for $HOME, and that's messing up the 'carefully spelled out' security policies, apparently. That's a problem, because there's no guarantee that $HOME will be under /home on *nix systems, particularly on servers or genuinely multiuser systems. Though technically difficult, that possibility needs to be taken into account by the snap ecosystem.

[Jamie Strandboge (jdstrand)]

@Terry

"As an aside, your description of what basically seem to be "hard coded"
paths for mounts and security policies explains a tangentially related
problem I'm having with snaps - on my system I use a non-default
location for $HOME, and that's messing up the 'carefully spelled out'
security policies, apparently. That's a problem, because there's no
guarantee that $HOME will be under /home on *nix systems, particularly
on servers or genuinely multiuser systems. Though technically
difficult, that possibility needs to be taken into account by the snap
ecosystem."

That is a separate issue (bug #1620771) from this bug and is something that is tunable, though it could be made easier by snapd (which is why that bug is still open).

[happydemic (happydemic)]

@Zygmunt, understood, users can't customise the location.

But surely the location could be a hidden directory?

Snaps are supposed to make Ubuntu easier for non-techie users, not harder, and putting this data in a standard directory under $HOME does not pass the grandmother test. If I put snaps on my grandmother's machine, she is going to think there is a virus called snap in her Home directory. Users are going to drive sysadmins mad by accidentally deleting their configs.

Why not use .snap if snap's hybrid config data means the usual options (.local/share, .config) are unsuitable?

I hope someone will think about this again.

[Zygmunt Krynicki (zyga)]

I think we might explore this but as any transition it is tricky business (given that snapd can be rolled back to a version that doesn't understand this layout).

In the interest of experimenting I will try to make a demo branch that uses $HOME/.snap instead, I'll keep this bug updated with details as I go ahead.

[John Wang (johnwang)]

@zyga Excellent news, thank you. I'm sure when the initial directory choice was made the snap team was under pressure to meet product deadlines (Touch/phone/cloud) so deferring a better solution until later probably made sense then; an argument can be made for a mandatory $HOME/snap directory being acceptable under an embedded/tablet/phone environment where the user isn't generally intended to have direct access to their home directory, but such arguments are much less defensible on servers and desktops. Unfortunately that postponement led to end users having snap packages using $HOME/snap installed on their systems, making the problem henceforth even more complicated to address, and it was starting to look like the snap team was going to wash their hands of this altogether and leave us with this very un-Unix-like immutable intrusion into /home, the filesystem hierarchy traditionally delegated to management by users.

[Mark Shuttleworth (sabdfl)]

I think .snap makes sense. Let's socialize that on the snapcraft list
and if there is no good reason otherwise we will make that the committed
plan. Timelines will be up to the team, it's not as high priority as
other elements of the roadmap such as secure tab completion.

Mark

[Jamie Strandboge (jdstrand)]

"Snaps are supposed to make Ubuntu easier for non-techie users, not harder, and putting this data in a standard directory under $HOME does not pass the grandmother test"

IIRC, the reason why ~/snap was chosen was precisely to pass "the grandmother test" since a snap's data is typically stored in ~/snap/<name>/.... Putting those files in a hidden directory (eg ~/.snap/<name>/...) means that "Grandma" may not be able to find as easily the document she just created.

That said, I see no reason why this cannot be revisited on the mailing list as Mark suggested.

[Mark Shuttleworth (sabdfl)]

Snap data is not expected to be accessed from $HOME anyway - each snap
will typically have its own way to display its own data. That's
certainly true on personal / convergence devices.

Mark

[GizmoChicken (gizmochicken)]

I followed a link from AskUbuntu to make a case for "$HOME/.snap" as the default directory.

But it looks like that's where things are headed, so I'm happy. :)

[GizmoChicken (gizmochicken)]

I agree with comments #2 and #3 regarding the urgency of this issue. As John Wang points out, it would be best to address this issue before the current data location becomes entrenched once more snaps are rolled out.

In comment #11, Mark Shuttleworth suggested that “$HOME/.snap” makes sense. I too prefer placing snap user data in the “$HOME/.snap” location. But I notice that flatpak places flatpak user data in “$HOME/.local/share/flatpak” in accordance with the XDG spec. See https://github.com/flatpak/flatpak/wiki/Filesystem So an argument could be made for placing snap user data in "$HOME/.local/share/snap" to conform with the XDG spec.

[Stego (stegomon)]

Much wanted!

[Stephan Henningsen (zta77)]

Today I installed an app that had unfortunately been ported to snap. Again I found my $HOME soiled with that unwanted non-hidden directory.

Could this please be moved off the "wishlist" and get some attention?

[John Lenton (chipaca)]

We can't really do this in a way that won't have unwanted consequences before we have epochs. Those are coming sometime soon (work will start in the next few months, at least based on the discussion at the snappy sprint: see the second whiteboard on https://forum.snapcraft.io/t/development-sprint-june-26th-2017/415/39?u=chipaca and possibly https://forum.snapcraft.io/t/when-are-epochs-stepped-upgrades-coming/758?u=chipaca for context), and after that we should be able to do this change (concretely, move from ~/snap to ~/.snap) if we agreed we'd like it to be this way (I think we do) and we agree on how to make the transition (I don't think we have).

[GizmoChicken (gizmochicken)]

@John Lenton, Thanks much the information. Good to know that this is receiving consideration. Much appreciated!

I'm not certain how the "importance" scale works, or what actual effect has. But so this doesn't get lost in the mix and forgotten, would you please consider upgrading the importance from "wishlist" to either "medium" or "high"?

[Oliver Grawert (ogra)]

wishlist seems to be just fine ...

from https://wiki.ubuntu.com/Bugs/Importance

- Wishlist: Missing functionality.
    ...
    - If it is non-trivial to implement, it should rather be written as a feature specification ...

part of this feature specification is the work on epochs...

[larpon (larpon)]

This has made me drop snap. I am to decide what the visible folders of my home directory are. I'll start using it again when this is resolved.

Until then; the AppImage format is a great alternative for distributing your apps in a sandbox (and it mostly stays out of the users way)

[David (lofidevops)]

Workaround while waiting for the rename:

Create a text file called ~/.hidden and put the word "snap" inside it. "snap" will now be treated as a hidden folder by Nautilus.

When "~/snap" is automagically be moved to "~/.snap" or (hopefully) "~/.local/share/snap" you won't even notice :)

Source: https://askubuntu.com/a/882964/7146

[Tom (tom-lorinthe)]

Last tip works really well for me: ~/.hidden file with snap in it ;)

[monaxos (neotheo)]

I tried Snap out today, but after seeing it clutter my home folder I immediately removed all Snap applications and uninstalled it. In my home directory, I like to have only my media and documents visible with all settings folders and such being hidden. Until now, most applications respect this and store their settings in folders with a . in front, or at least allow you to customize where settings are stored. Snap doesn't allow me to do this. Being unable to change this makes Snap unacceptable for me. I think it is highly unfortunate that the location where the settings are stored should be in such a garish way and can't be altered. I am also sensing a lot of hesitation from the developers in changing this behaviour citing that it is difficult. Nevertheless, I, and I suspect many others, won't use it unless this bug is fixed.

[Zygmunt Krynicki (zyga)]

Hello, snapd developer here.

I just want to clarify what is going on. Changing this in the source code is possible but not very easy as the value is spelled out in a very peculiar way in the apparmor profile for snap-confine and all the snaps. We will eventually get there bug we need to implement the epoch system first so that we can ensure that users who migrate to ~/.snap (or whatever else the path is) won't be able to go back to a version of snapd that doesn't understand this. This is the work that John referred to.

[Oliver Grawert (ogra)]

I'd like to note again that ~/snap is not just simply a configuration dir as some people here seem to think (else it would probably have been dot prefixed from the start), but ~/snap/<packagename> is the default dir where your snap stores data that you want to be user accessible, might put additional binaries, scripts etc you want to execute...

it is way more than a configuration dir, it is the fallback homedir for the snap if it does not use any interfaces, it is the place where downloads can end up without having to use any interfaces and last but not least it is the default workdir that user started snap applications run in (vs $HOME which a non snapped app without security confinement would use, with access to all your sensible data)...

all these bits will be completely hidden once that dir moves and we will have to explain to users that the output of that cli command they just used can only be found if they turn on hidden files in their file browser... or that the download they just did with that gui program ended up in a hidden space ...

while it might seem trivial to some to just move the dir name, there is a lot of conceptual work to be re-done and re-thought to not lose in security and usability when hiding it ...
(along with the fact that you can always roll back to any former snap or snapd version and due to the fully transactional nature of snaps this needs to be fully backwards compatible as zyga mentioned above)

...so please be patient ;)

[Jonatã Bolzan Loss (jbopen)]

Hi Oliver

We certainly understand the implications of this. Just to consider: how will I explain to my grandmother that the photos she just downloaded (using a snap software) are not on her friendly Home folder /Download or /Pictures, but the photos are stored inside the <software name> folder that is inside the <snap> folder that is inside her Home folder...? You see...

Really, the solution is not hiding the snap folder, but maybe making the snap software being able to access the Home folder/content... I know that it's not secure as it is intended with Snap packages, but I think that all of us agree that considering the "~/snap/<sofwarename>/" as the Home folder is definitely not user-friendly.

For a geek or a developer it is Ok, but for regular users, they should just look at their files in home folder, with their usual subfolders, as beautiful and comfortable as it always was. Regular users should not know (they don't need to know and they will not want to know) about this snap stuff, they just want to download the application from Gnome Software and use it in their Home folder.

We are patient, don't get us wrong :D The actual behaviour is not bad, it is just ugly.

Thanks for your attention.

[Oliver Grawert (ogra)]

... "how will I explain to my grandmother that the photos she just downloaded (using a snap software) are not on her friendly Home folder /Download or /Pictures" ...

luckily when using the home interface (and hopefully once your granny starts using snaps the app integration will be at a level where it will ask for permissions in a popup (similar to UbuntuTouch, IOS and lately even andoid) once the app tries to download something for the first time), work is being done in gnome-software for this), this is exactly what happens nowadays ...

but there are still developers that do not want to use interfaces, there are still cli apps (and will ever be) that want to put their output into their $WORKDIR etc etc ...

when snap stated there was no other secure way to solve these issues, interfaces were still rare and initially limited, having bits visible in the file manager in $HOME/snap was a good compromise (and still is IMHO).

What i was reacting to is:

"...Until now, most applications respect this and store their settings in folders with a . in front..." from a former commenter ...

$HOME/snap is not a config dir (and if we do actual config-only dirs they would most likely land in $HOME/.config/snap or some such to properly adhere to the established filesystem standards), it is the snaps home and workdir for now and the one securely accessible space for developers that do not want their snaps (be it server, desktop or cli apps) to use interfaces.

[Jamie Strandboge (jdstrand)]

"Changing this in the source code is possible but not very easy as the value is spelled out in a very peculiar way in the apparmor profile for snap-confine and all the snaps."

Actually, this isn't particularly difficult in and of itself. We could simply drop the complicated bit in the home interface we have now that carves out the snap dir (since it won't be special any more_ then simply allow @{HOME}/.snap/... by default.

The problem is all the other details that Zygmunt and Oliver mentioned, plus other things (eg, do we allow both directories? If we allow both, what does that mean for the home interface? Do we allow compatibility symlinks? Do we do a data migration? Do we do data migration upon revert of the core snap? What happens to applications if the only core snap is reverted, if only the app snap is reverted, if both are reverted? How do we handle snaps that hard-code ~/snap/... instead of using $SNAP_USER_DATA and $SNAP_USER_COMMON (this might be more common than you think-- I know of a lot of examples that use getent/getpwent() for things-- they may then be depending on being able to just tack on 'snap/<name>/common'? These questions are just the ones OTOH, I'm sure there are others.

Like Oliver said, there is conceptual work. Whenever this is implemented, I very much expect bugs coming in for what Oliver mentioned: "my snap's data is not discoverable because it is in a hidden directory" (which was the reason why it is 'snap' now instead of '.snap'; we had the same debates on 'snap' vs '.snap' when decided on this long ago).

[John Lenton (chipaca)]

Oliver, the argument that ~/snap/<app> is “not just simply a configuration dir” isn't particularly good, I think, as the same could be said about the triple XDG directories for data, config and cache (all of which default to be hidden).

It is the nature of the confinement that we build that these directories cannot be relocatable by simply setting something in the user's environment, and so we need to find something that works for all users.

We've already agreed to move it, and are slowly taking the steps towards that. We'll get there.

On the subject of having access to e.g. XDG user directories, again it's tricky because they're relocatable by the user, but I think something like the phone's trusted helpers (like the content hub), which the flatpak people are now calling portals, are the way to handle that.

[aaronfranke (arnfranke)]

Rather than just moving it, please allow it to be configurable. Hard-coding anything is a very bad idea.

[GizmoChicken (gizmochicken)]

"Rather than just moving it, please allow it to be configurable. Hard-coding anything is a very bad idea."

With regard to a directory that is intended to be user accessible (as opposed to one that contains configuration files), I'm all for reconfigurability.

But with regard to the locations of pure configuration files, I hope (and assume) that they will be hard-coded to an appropriate location. I'd be perfectly content with the proposed “$HOME/.snap” location. But just to repeat, flatpak places flatpak user data in “$HOME/.local/share/flatpak” in accordance with the XDG spec. See https://github.com/flatpak/flatpak/wiki/Filesystem So an argument could be made for placing snap user data in "$HOME/.local/share/snap" to conform with the XDG spec.

P.S. I realize that, from a developers point of view, this issue may seem trivial compared to the much more import issues that the developers are fixing. And I'm surprised that term "bikeshedding" hasn't been mentioned in this thread. But as you can see from the "heat" of this report, having a visible "snap" directory (with a lower case "s") being forcibly placed in the home directory is disturbing to many.

Speaking for myself, if snap requires a visible "Snap" directory to appear in my home directory (upper case "S" consistent with other visible default directories in my home directory), although not ideal, I could live with that. But I anticipate that many would continue to complain. So it would be better if the name of any visible directory appearing in home is configurable.

[machrider (machrider)]

I personally love it when half-baked projects drop shit in my home directory.

[Chris Meyers (sulobanks)]

+1 for moving the snap directory to a more standard place and hiding it. The way I see it, you have two choices for a folder like this (and all other software I use conforms to this):

1. Make it non-configurable and hide it in a standard, widely accepted location (~/.<whatever>, .local/<whatever>, .config/<whatever>)
2. Make it user-configurable.

Or you could get really crazy and do both.

But creating a visible, non-configurable folder directly in the user's home dir is just plain bad. You'll get nothing but complaints. People who don't like it there or want it spelled with an upper case 'S' or want to call it 'Applications' or something. This is actually worse than littering the file system with loop devices. :-P

[Manuel Grießmayr (dccoder84)]

Many thanks for polluting my home directory. Also if the snap directory isn't available my Home dir will be polluted with empty dirs like Downloads, Music, Pictures etc.

[Oliver Grawert (ogra)]

@manuel: this is definitely not happening on any of my systems and surely not normal (creating any of the XDG dirs i mean), are you sure you do not simply have a badly written snap that has the home interface connected and uses a broken startup script (you should talk to the snap developer in this case ... typically "snap info <snapname>" shows a "contact" field to find an address for this.

[Seif Allah Tarhouni (saksow)]

Very smart package manager, except for this very bad design. Please fix it, thanks.

[Fanjin Zeng (fanjin)]

This bug report has been opened for almost 2 years! It should be an easy fix!! Stop polluting my home directory, please fix. Thanks

[Fanjin Zeng (fanjin)]

I completely agree with @gizmochicken (#19), the importance of this bug is underrated. This is the second hottest bug in snapd, it has been opened for almost 2 years and is affecting every user. In fact, I have never seen any other open-source software occupying home directory without asking user permission (Even software in Windows system won't do this). I don't think this is just a 'Missing functionality' issue, such intrusive method is definitely hurting Snap's reputation. @neotheo (#24) is right, many people may not use snap again because of this.

Most of comments above agree on changing to '$HOME/.snap', I personally prefer '$HOME/.local/snap'. Either is much better than current location. I hope this will be fixed soon.

[Gustavo Niemeyer (niemeyer)]

This is the second hottest bug because it's very easy to have an opinion about it without any strings attached.

As I believe was explained multiple times above the real reason this is not "hidden" is that snap/ is not just a configuration directory. This is where the writable space for all snaps live. For them to be able to write anywhere else they need interfaces that would allow them to do so.

As a trivial example, this is content I have in my snap/ directory right now:

$ ls ~/snap/telegram-desktop/current/Downloads/*
VID-20180204-WA0007.mp4 VID-20180214-WA0008.mp4

Hiding this directory has an important unintended consequence which I'm sure you won't like either: it encourages packagers to use less strict confinement. For that specific reason, we won't change that just yet.

Instead, we're working on better ways to allow snaps to have access to read and write data in the system in a controlled way. After that happens, we WILL remove this directory from your homes into a better place.

Meanwhile, apologies for the inconvenience.

[GizmoChicken (gizmochicken)]

"Instead, we're working on better ways to allow snaps to have access to read and write data in the system in a controlled way. After that happens, we WILL remove this directory from your homes into a better place."

Thanks much!

[Joel Teixeira (joelfft)]

Really sad to uninstall snapd but imagine if all other software decide to create just one folder on $HOME. The fact the isn't just a configuration folder doesn't seem to justify the inability on usr side) to choose the right place to hold this data. About the example with telegram downloads, would be really easy to symlink its downloads "~/Downloads/Telegram".

I'll be waiting anxiously to give Snapd another try after this bug fixed.

Thank you.

[Alexey Kulik (doctor-rover)]

@Manuel Grießmayr (dccoder84) wrote on 2017-12-30 (comment #35)
"...Also if the snap directory isn't available my Home dir will be polluted with empty dirs like Downloads, Music, Pictures etc."

This is another bug: Bug #1746710 - Snap creates redundant duplicate directories in home folder Edit

[Gustavo Niemeyer (niemeyer)]

No worries, Joel Teixeira, we'll still be here if you need us, working on developing modern package management for Linux, and hopefully making it good enough that people will be excited to use despite the name of a directory not being their preferred one.

In fact, we can definitely work allowing a per-user configuration setting so everyone can tune the name to their own preference. If you're doing that, it means you know where to find the data, and so we don't need to be worried that important information is tucked away in an obscure location.

If there's enough support for that, we can put it in the roadmap for sooner rather than later. That will actually help even for when we do the actual transition into the hidden directory, as it means we could keep existing directories untouched so we don't break anything and people don't get confused by data moving.

Yeah, that sounds like a good idea. Will provide more details about the plan in this forum topic:

https://forum.snapcraft.io/t/change-home-snap-to-snap/1827

[Joel Teixeira (joelfft)]

Thank you Gustavo Niemeyer, I'm really anxious to try snapd again and I feel like this is the future of linux applications packaging. So yes, it's just a matter of time. I read the forum discussion and the idea of .config/snap (configuration) and .snap (apps) is just perfect on my expectations. While it doesn't seem important for many, it's clear many users feels intrusive the actual folder disposition. For one, I can say I'll follow closely for this change.

Have a nice week, regards.
Joel Teixeira

[Tobi Schäfer (interface)]

> imagine if all other software decide to create just one folder on $HOME.

exactly.

[Stephan Henningsen (zta77)]

I may be misunderstanding niemeyer's message, but just to be clear...

"[...] hopefully making it good enough that people[¹] will be excited to use despite the name of a directory not being their preferred one."

What's this now? "People[¹]" covers "everyone except the snap developers" you know. There are best practices for naming configuration files and directories, and they have even become standards. And even if wasn't there's still common sense. Placing a non-hidden directory in everyone's home dir conflicts with all of the above.

"If there's enough support for that, we can put it in the roadmap for sooner rather than later."

Good. Sooner it is then, since this bug report and all its comments clearly shows that people[¹] want it changed.

Btw: Does "no longer affects: snappy" mean that is has been fixed?

[John Lenton (chipaca)]

> Does "no longer affects: snappy" mean that is has been fixed?

No, it means snappy is the wrong project for this bug

[GizmoChicken (gizmochicken)]

>I may be misunderstanding niemeyer's message, but just to be clear...

The key point can be found in message #40, namely:

"we're working on better ways to allow snaps to have access to read and write data in the system in a controlled way. After that happens, we WILL remove this directory from your homes into a better place."

I, too, hope that the "$HOME/snap" directory will be moved. But some things need to be completed before the move can happen. Let's continue to be patient.

[Lúcio Boari Fleury (lucboari)]

I can't believe you're going to ship Ubuntu 18.04 without fixing this carnival on my home dir

[Alan Diggs (schyken-deactivatedaccount)]

Also an issue for me, almost two years later. Between a configurable name for this folder or it at the very least aligning with the proper spec, something needs to be done about it. "Wishlist" is a stretch. It's an excuse not to implement a solution.

These things may appear trivial on the surface, but trivial things collectively result in a subpar experience. Especially with such a push on this platform, things like this need attention.

(As a side note, Snap has come a very long way since its conception. I'm very impressed, and I hope it will one day be a valid and compelling platform for developers and end users.)

[aeronutt (aeronutt)]

Please fix. Until then, I'll disable snap on my version of 18.04.

Why? I think the developers may be missing the point. Standards are standards for a reason, and when you arbitrarily ignore either standards OR common practices, you imply your software isn't ready for production. Creating an arbitrary visible directory in my HOME directory (it's called home for a reason) seems quite pre-production, implying nothing under the snap 'name' is ready for primetime. What else is the software doing that's atypical? It does not give me faith in the current status of snap.

[Jawtheshark (jawtheshark)]

I came to the same conclusion as aeronutt. Snaps - as is - are at best pre-production. When I saw what it does on a 18.04 LTS (like having a plethora of loopback devices, having serious performance issues), I decided to get rid of it.

Not only that but having default applications (gnome-system-monitor, gnome-calculator) to be installed as snaps is just... insane. That's the kind of stable software you want in normal packages (.deb). The only thing I see that snaps are good for is third party commercial software. For that it's a relatively decent solution, because they are system independent and statically link.

Still, look at Steam or Skype... Two very successful third party applications: they provided debs just fine.

If Ubuntu goes snap-for-everything, I'll need to go back to something more sane.

[Gustavo Niemeyer (niemeyer)]

The snap infrastructure is used in production by us and many of our customers, and we also regularly hear about success stories from the community. So in that sense, yes it's production quality, today.

That said, Ubuntu will not replace all debs by snaps. These are complementary technologies, and the rare replacements are special cases that had specific discussions behind them.

[kerozoli (kerozoli)]

I didn't create a screenshot before I removed snapd from my SuSe install, but let me reuse one from a previous comment:

https://launchpadlibrarian.net/364034938/Captura%20de%20tela%20de%202018-04-09%2011-33-10.png
Is this production quality? And this issue opened in 2016.

[Oliver Grawert (ogra)]

@kerozoli you seem to be mixing up this bug with bug 1746710 (which is about redundant untranslated XDG dirs ... seemingly created due to a bug in the desktop-helper application code and not related to snapd at all) this bug is about the "snap" subdirectory in your home where applications put their user accessible data (which makes it under current design a required thing, design changes are being worked on as gustavo noted above but will take time)

[kerozoli (kerozoli)]

Thanks Oliver for the clarification and sorry for misunderstanding

[Damon Revoe (revl)]

Until this bug is fixed, I'm not using snaps, period. Technical difficulties should not be addressed at the expense of user experience.

[Nick Mann (nmann84)]

This really should have a higher priority. I am uninstalling all of my snaps and refusing to use snaps until you allow us to hide this directory (i.e. rename it to ".snap"). Apparently I'm not the only user who feels this strongly about it judging by the comments. I'm sure there are 10 times as many of us who aren't making comments on this bug.

[GizmoChicken (gizmochicken)]

@nmann84 I fully agree that this issue should be marked with a higher priority. But as mentioned by @kwill in comment #22, there's a pretty simple workaround, namely:

"Create a text file called ~/.hidden and put the word "snap" inside it. "snap" will now be treated as a hidden folder by Nautilus."

I don't understand the details, but @niemeyer stated the following in comment #40:

"we're working on better ways to allow snaps to have access to read and write data in the system in a controlled way. After that happens, we WILL remove this directory from your homes into a better place."

So, I guess you could say that the status isn't just "confirmed" but is more like "'confirmed' and awaiting completion of other work, after which will be 'in progress'" (if such a status existed).

[Oliver Grawert (ogra)]

The point here is that not every snap uses the home interface (by choice of the developer (because she considers it more secure), because they were initially developed for UbuntuCore (where home does not auto-connect) or because they ship server-only apps (but perhaps still want to provide data to the user)).

The data of such snap packages is *only* accessible via ~/snap/<packagename>, if you simply hide the dir (which would likely be a trivial code change), you make data of such apps inaccessible (or at least very hard to find).

It needs a bigger conceptual re-design to not break such snaps, not all snaps are desktop apps and not all snaps blindly use a plethora of snap interfaces, to fix this bug they need to be taken into account as well...

[maxwellcom (ndmaxwell)]

A full (redesign) solution is ideal, but the workaround posted by @kwill in comment #22 and repeated by @gizmochicken in comment #60 worked well for me - thanks for the nautilus tip!

"Create a text file called ~/.hidden and put the word "snap" inside it. "snap" will now be treated as a hidden folder by Nautilus."

[Naw Dude (spamsaq)]

Discovery of an unwanted ~/snap/ directory and a bit of googling brought me here. I am firmly aligned with most of the arguments in this thread against a mandatory non-hidden ~/snap/ directory. The treatment of 'wishlist' here is inappropriate. For every person on thread saying they won't use snaps until this directory path is configurable or .snap by default, i'd guess there are a significant number (100? 1000?) more who won't bother to say anything at all. Many linux users are quite particular about their environments, especially the state of their desktops and $home, myself included. Refusing to honor a long-standing convention here is probably irritating and alienating a whole bunch of users. /signed

[Zygmunt Krynicki (zyga)]

Hey everyone

This update goes to a lot of people so I will be brief. This is still on
our roadmap but unlike what you may think, is rather non-trivial to pull
off. We are committed to making this change possible when we can ensure it
will not break existing installations and doesn't close the road back (via
snap rollback).

We will fix it, it's just not immediate.

[Gustavo Niemeyer (niemeyer)]

It's not even just that. Part of the confusion here is that people think this is content that should be hidden, but it's really not. This is closer to "~/Documents" than it is to "~/.config". The directories under ~/snap hold the $HOME for snaps. They are the place strict snaps can write to, unless they have a home interface. That's the real reason why it wasn't originally cooked under ~/.something.

Per earlier notes, we are working on a richer mechanism, and once that lands we'll review the situation again. Meanwhile, apologies for the directory not having the name some of you would like to have.

[Tony (tonv)]

Impressed with snap, but reluctantly will now uninstall it and all snap apps, because of "snap" rather than ".snap". This is not a matter of aesthetics, it's a matter of getting the culture.

[Krisztian Nagy (nkrisztian89)]

I get your arguments as a fellow dev (why it is not trivial to change, why it is not hidden by default). I also get why it is irritating to users, it is to me as well. And I don't think the dev arguments hold very well from the user friendliness perspective. Below I will try to illustrate this with a use case and share a proposal/idea for a potential user friendly workaround:

You argue that the current solution passes the 'grandma test' because 'grandma' (non-tech user) might want to find the files she just created by this snap app that fails to use the home interface, to send them in an email. That's why the snap folder is not hidden, to ensure she can find them. This would mean she has to look for the files in e.g. ~/snap/MySweetApp/38. Not knowing it is a snap app (and what snap apps are or that they exist in general), possibly having many snap apps in the snap folder (might not even know the name of the app, just the icon that needs to be clicked to launch it), and possibly multiple revisions (which by default will be organized in ascending order). This certainly sounds like a stretch to me. Seems more likely that the user will just think the app is broken and fails to save the files. I think making the directory hidden or not makes negligible practical difference for such use cases.

What I would do (until epochs and whatnot are implemented and the snap folder can be moved), is something like this:
- create a folder with a localized (!) name corresponding to something like "Application data", that means something to the (potentially not English speaking) non-tech user and doesn't feel out of place next to Documents, Pictures etc in the home directory (or even inside Documents)
- have the current revision workdir of every snap application be symlinked there (so e.g. "~/Application data/MySweetApp" -> ~/snap/MySweetApp/current) when it is created
- make sure that "snap" is included in ~/.hidden so it doesn't clutter the user's home dir

(or well, you could just hide ~/snap with ~/.hidden and make "Application data" itself a symlink to it, though that could make the different revisions still confusing for non-tech users, but also would be easier to implement)

This would be my solution to attempt to have the cake and eat it too: the user will have a pretty home folder and more chance to find the data files because of the more descriptive folder name, while at the same time the code relying on ~/snap will not break. I don't know about the feasibility in terms of how confinement works with symlinks and such, maybe that would make things too complicated. These are just my two cents, maybe something like this can help if implementing the original change takes very long (which can always happen). Sorry for the long post!

[Gustavo Niemeyer (niemeyer)]

Hi Tony,

Stepping up on a culture pedestal and looking down on others is pretty unhealthy, even more if you do that blindly.

As was repeated many times in this thread, the files inside ~/snap must *not* be hidden. Those are going to be music files, documents, pictures, which strict snaps want to make available. That's not content that should go unperceived no matter how your culture looks like.

It's also instructive to consider history in this context. Hidden directories as they are known today were not supposed to be hidden in the first place. The original intention was preventing "." and ".." from being seen, but the assembly logic was miscoded, and the bug was abused until it was too late.

So we are in good grounds both culturally and historically, yet we've been repeatedly saying we *do want* to improve the situation even further, and have on going work for that.

If that sounds unreasonable to you still, we'd likely be unable to please no matter what.

[Gustavo Niemeyer (niemeyer)]

Hi Krisztian,

There's no <stereotypical human being> test here. Those are just user data files which need to be exposed, whether you're young or not. That said, your general sense is right: we want those exposed, and nicely so. You're also hitting the right points when you raise symlink and confinement issues. That's part of why we cannot just rename the directory overnight, and why it's an even larger issue when you account for translations.

But we'll definitely improve it further, in multiple ways.

[Zygmunt Krynicki (zyga)]

The name ~/snap cannot be localised as it is encoded in a very specific way in apparmor profiles for snap applications. Those do not vary per user. Just wanted to share why this is difficult.

[Gustavo Niemeyer (niemeyer)]

It can be translated. It's software.. everything _can_ be done. It's just more complex, and not necessarily the best idea given potential options.

[Mantra (mantra)]

"As was repeated many times in this thread, the files inside ~/snap must *not* be hidden. Those are going to be music files, documents, pictures, which strict snaps want to make available. That's not content that should go unperceived no matter how your culture looks like."

That's not true. I had no idea what "snap" was in this context, until I found a snap folder in my source control repository, and had to find out what it was. And what's in mine? A single subfolder called "gnome-system-monitor". I'm pretty sure that isn't a music file, or a document, or a picture, or anything else that I'll ever want to look at (or keep under version control).

Sure, it's easy enough to add to run "echo snap >> ~/.hidden"... and to alias ls to ls -Isnap ... and to add snap to .gitignore ... and to .hgignore ... and to revert the latest changes to git and mercurial (provided I haven't pushed it anywhere, which fortunately I hadn't).

But it's a right pain in the derriere.

:)

[Marko G (vxmxpx)]

I've read some comments, and I do get your reasoning, but, I think it's a poor reasoning. Because, I'm having hard time believing that non-technical, or even technical, users would do the following: save a file and then browse snap folder, browse among many folders in there to find (often illogical) app name, open "current" under the app name, and browse whatever elaborate file structure they find inside "current" to come to their file. Making "snap" folder not hidden is completely useless UX vise, all you did is enrage people who don't wanna have their home littered.

Also I've checked my snap folder now, there's an empty slack folder inside, and tmnationsforever which has empty current, but added common which buried deeply contains configurations and replays, etc... You should check how this folder is even used, I have feeling there's like 1% of useful data users would wanted to access often (or at all), and the rest is rubbish.

[Davide (davide-cester)]

Hi everybody,

I just wanted to say that I agree with the many asking for the moving of the "snap" folder. Although it is clearly not a life threatening issue :) I strongly believe that the visible content of $HOME should be in total control of the user for a variety of reasons, not excluding personal taste. I also think comment #73 above is a realistic reply to the only argument in favor of having ~/snap visible.

[Viktoria Nemkin (nemkin)]

The naming of the snap directory does not fit into the default xdg scheme, which is strange and annoying.

On a fresh Ubuntu install you see:

Desktop Documents Downloads Music Pictures Public snap Templates Videos

[Mike Gioia (mikegioia)]

I'm also impressed with Snap but have to uninstall it over this. It's really unacceptable that this isn't either configurable or in ~/.config. Please fix this.

[dreamcat4 (dreamcat4)]

I am with comment #73 to #76 entirely. Anyhow. Not sure to what degree this suggestion is still relevant, but I would like to add a tiny bit more to it.

[dreamcat4 (dreamcat4)]

It seems from prior comments, that while this system was still being developed... well it was not clear yet precisely how apps might be using this folder. What stuff they could be writing in there. So might have been considered instead from the outset?

The suggestion was already discussed of course...

* To hardcode the apparmour profile loctions to some hidden .dot folder.

While I do think that hardcoded FULL PATH locations are fundamentally bad, it does seem that most people are just considering purly the relative path aspect. Without actually understanding how bad this really is.

Nevertheless, if you guys are going ahead with this, then I would still like to tack on a little bit extra to that above ^ accepted solution. In my example I call the hidden folder '~/.snaps'....

Then also:

* Create a standard unix symlink from that hidden folder to 'appear' as '~/Snaps'. By default.

(that is, if you still honestly believe that in reality, people actually desperately need to access inside of this folder, as a visible folder. which i personally don't belive, not anymore, simply because the way the vast majority of real snaps are doing things now / these days).

* Create a very simple textfile named '~/.snaps/README.txt' (or similar) inside that folder. To explain to people what to do about this folder. Because it's non-trivial to grasp.

The README.txt file would present a pretty basic explanation of what this folder actually is. What is being stored inside it.

[dreamcat4 (dreamcat4)]

Example:

Just enough for them to understand with enough clarity what this folder actually is. What it is for.
Written in plain english (--> then translated / Localized, assuming that is possible for the other languages).

~/.snaps/README.txt:
=====================

* This folder contains your user data, from your snaps applications.

* For any given application, the current user data is always kept in it's '<APP_NAME>/current/' subfolder.

[non-generic wording, that references apple/iOS]

* For ubuntu snaps, this is our equivalent to the 'App Data' of Apple's iOS Apps. The sandbox User Data folders for each individual App. In other words the: 'per Application Data' sandboxes.

On Apple i-devices, these files are always completely hidden from the user. Unless shown within the app itself. That is to say, the folders in the filesystem are not visible or accessible by any other means.

Each sandbox contains all of your custom User Data for each Application. Such as settings, plus any other user specific information which you might have entered into that application. Or anything else that the application might automatically save for you, on your behalf. For example temporary cached data, which is also stored in the neighbouring '<APP_NAME>/common/' subfolder for each app.

[alternatively, you could instead make a similar analogy to android apps, or use a completely generic wording that does not reference mobile phone platforms, however it is a good analogy, because users are already familiar with this]

[generic wording]

* It is a sandboxed location, for security. So that each app can only read and write user data. Each app has it's own individual sandboxed folder.

However some specific applications [not that many it seems... so maybe provide us a concrete real world example of one?] might save really useful data in there! For example a Documents program, like a text editor, or a file Downloader, or a Paint program. The type of data that you will also want access from outside of the snap application. And use in other applications.

We are working at making that data easier to access when needed. With a common and unified mechanism, that is supported across all snap applications. [However that ideal solution is still a long way off at the moment.]

In the meantime, if you do require frequent access to certain specific user data, and it is being written somewhere within this folder, then we recommend taking the following action:

Create a symlink from those subfolder(s) into your ~/Documents folder. Or wherever you prefer, your ~/Desktop, etc. To make it easier to find and access. Do not move around and of the folders inside of ~/.snaps/. Because they are hardcoded locations linked to AppArmour profiles, (part of the sandboxing / security mechanism).

[maybe re-arrange or re-emphasise different sections]
====

[dreamcat4 (dreamcat4)]

Actually my above example is far from ideal. But those would be the general kinds of ideas to convey to people.

[dreamcat4 (dreamcat4)]

I also found these previous comments (by developers maybe?). They were phrased Rhetorically, as examples. However it feels constructive to actually try to answer them. To see what other work is required.

Goto ---> Jamie comment #29
============================

> The problem is all the other details that Zygmunt and Oliver mentioned,

Goto ---> Zygmunt comment #25
==============================

> [cleaned up] the bug we need to implement the epoch system first (for snapd) that doesn't understand this. This is the work that John referred to.

[RECAP] yes, that is definately a critical problem for lts releases
you said you are already working on it, thank you, very kind, it is the other bug elsewhere.

Goto ---> Oliver comment #26
=============================

Now this bit is rather repetitive...

But it's a case of trying to cover all the different angles / bases.
Without forgetting or ommiting anything (to not make another slip-up again).
Most times, the answer is the same (regardless). However sometimes it isn't.

> it is way more than a configuration dir, it is the fallback homedir for the snap if it does not use any interfaces, it is the place where downloads can end up without having to use any interfaces

Then the snap is not written very well.
Because it didn't implement interfaces (but needed to).
Anyhow, solved by my suggestion. Not a problem.

> and last but not least it is the default workdir that user started snap applications run in (vs $HOME which a non snapped app without security confinement would use, with access to all your sensible data)...

Then the snap is not written very well.
Because it didn't implement interfaces (but needed to).
Anyhow, solved by my suggestion. Not a problem.

> all these bits will be completely hidden once that dir moves

(so far!) Then the snap is not written very well.
Anyhow, solved by my suggestion. Not a problem.

> and we will have to explain to users that [something complicated]... or that the download they just did with that gui program ended up in a hidden space ...

Then the snap is not written very well.
Because it didn't implement interfaces (but needed to).
Anyhow, solved by my suggestion. Not a problem.

> while it might seem trivial to some to just move the dir name, there is a lot of conceptual work to be re-done and re-thought to not lose in security and usability when hiding it ...

(overall conclusion for those bits ^)

Either:

The snap is not written very well.

OR:

Solved by my suggestion. Not a problem.

================================================================================================
Suggestion was: 1 symlink + README.txt file. Can / does solve these above concerns for me ^^.

[dreamcat4 (dreamcat4)]

But there's more.

Goto ---> Oliver comment #26
=============================

> (along with the fact that you can always roll back to any former snap or snapd version and due to the fully transactional nature of snaps this needs to be fully backwards compatible as zyga mentioned above)

Yes agreed. It would seem that is a heavy consideration because this is an LTS Release now.

[expanding on this concern]

I would suggest that this, as a break change (fixing the epoch and preventing version rollback) in LTS... it should be done during a period when no other features or bugfixes are being released for snapd. That will significantly reduce the risk of any other bugs sneaking in there, on UNCONNECTED features. Which might otherwise require the user to roll back. For unconnected reasons. Then the risk is minimized as much as is feasible.

> ...so please be patient ;)

Yes. But after 2 years of open bug, can we get a more updated timeframe on that?
For example: is 4 years a realistic expectation? Given other broader milestones?

(... that would mean by the next 20.04 lts release)

This fix is aligned with the epoch feature milestone in snapd.
But are there any other pressing large milestone requirements?
Because I cannot seem to find them.

So what is stopping to get the rest worked out, and lined up in the meantime?
To make sure that it's ready beforehand.

Either the belief is that all this other associated work is far too complicated.
And demands a big block of time dedicated to it. (which is pointless without epochs)

Or the belief is that this work is actually far too simple, compared to snapd epochs, which is still very far away.

Therefore it would not matter to do nothing here. And be best / more tidy to just dedicate all the time to epochs first instead, and get that fully out of the way. Since that is critical for this one. Then come back to this afterward. (if we needs only spend a tiny little time on this bug, it wouldn't make any difference).

> plus other things (eg, do we allow both directories?

Nope. Absolutely not. Because there is only 1 environment variable (SNAP_USER_DATA=)

> If we allow both, what does that mean for the home interface? Do we allow compatibility symlinks?

You probably do not need to worry about that ^^. If you did 'no' for the previous question.
And if you do not permit duplicate real folders (of the same thing...)

> Do we do a data migration?

If you want to move ~/snap to a hidden folder, then create a symlink in its place.
That is probably fine by most people. And it solves the previous question.

> Do we do data migration upon revert of the core snap?

I am guessing that this question was already answered previously above ^^, but i'm not sure.
Maybe its about something else instead IDK.

> What happens to applications if the only core snap is reverted, if only the app snap is reverted, if both are reverted?

I am guessing that this does not happen very often, typically never.
Unless there is a pressing technical reason which forces the user to revert a snap.
Therefore I believe that this is unlikely to matter much.

At best, if the app cannot find it's user data anymore, and writes to the wrong folde...

[David Aslan French (thedonquixotic)]

Just wanted to add in that I would also like to see this feature implemented.

[chrm (ubuntu-one-3)]

The workaround "echo snap >> ~/.hidden" doesn't work for me.

[Andrew Evdokimov (kraamis)]

Question to the developers. Can you report the latest news on the time of correcting this error?

[Bast1aan (bast1aan)]

Another issue with the ~/snap folder I run into now is that it also contains cache data that should go to ~/.cache. For instance I have spotify cache folder of over 2GB in ~/snap/spotify/common/.cache that can't be easily excluded in backup scripts. The separate ~/.cache folder is invented to address this.

[Ernst Rohlicek jun. (ernst-rohlicek)]

Placing applications into $HOME/snap/ is annoying.

[David Aslan French (thedonquixotic)]

I'm very new to development. I'm really more of a designer learning to code. But I find it kind of bizarre that someone who was smart enough to make the Snap project would be.... not so smart in this ugly design choice. WTF? Like this seems very un-linux like.

[Adam L Taylor (adamltaylor)]

Once upon a time, basically all Unix applications abided by a simple rule: Don't create (non-hidden) files in the user's home folder without asking first. I find it completely maddening that application developers have stopped abiding by this rule. The home folder is *mine*. I should get to decide what goes in it, and where. The whole business with XDG user dirs violates this principle, and is therefore a huge mistake, in my view. (But at least you can delete those stupid things and (mostly) make it so they don't get re-created.) This business with ~/snap is just completely abhorrent to me. I deleted all the snaps on my system and installed things the old-fashioned way so that I could get rid of ~/snap. And then to have this issue marked as a mere "wishlist" item is just rubbing salt in the wound. And this crap about "some applications have to create non-hidden files in their snap folders for security!". No, they don't. They need to follow the simple rule: Don't create files in the user's home folder without asking. If those applications need to create files that a user may need to find later, they need to a) get permission to write in the user's home folder, and then b) ask the user where they want the file saved. Anything else is useless to me.

[nosilver4u (shanebishop)]

A year later, and this still exists? I've never had a snaps folder in my $HOME, I upgrade to 18.04, and all of a sudden this random folder appears in there. I don't even know what snaps is, nor do I care. Please invent a time machine, go back to when snaps were first a thought, and do it right the first time...

[David Aslan French (thedonquixotic)]

Hey guys, just wanted to say I found a workaround! Well as long as your'e using nautilus.

https://github.com/brunonova/nautilus-hide

It's a nautilus extension that adds files to a ~/.hidden folder that Nautilus then reads to know what to hide and what not to hide. So far it seems to work great!

[David Aslan French (thedonquixotic)]

Oh I should clarify, it adds the file names to .hidden, but leaves the actual folders untouched. This should mean that when you install another snap file or whatever it doesn't just create a whole new folder all over again.

[Ivan (ivanperez-nfm)]

In 18.04, this has become the default behaviour of the calculator. If the snap directory is removed, it appears again when the calculator is opened. So this affects the default installation of Ubuntu, and the gnome-calc project too.

This is *very* bad design, and bad public release policy. It should not be a default, and it should not be the default in a stable release of Ubuntu.

[chrm (ubuntu-one-3)]

On Ubuntu 18.04 there are normal versions and snap versions for some
utilities. You can replace the snap versions and get rid of snap. The only
problem is that some things only come as snap versions. For me that is the
Heroku CLI.

List all installed snaps:

$ snap list

Remove them all:

$ sudo snap remove gnome-calculator
$ sudo snap remove gnome-characters
...

Install the non-snap version:

$ sudo apt install gnome-calculator
$ sudo apt install gnome-characters
...

Then remove snap:

$ sudo apt remove snapd

[yak mandango (yakmandango)]

$HOME/snap is for user content. User content should be user-accessible. However, it looks like the feature is not very user-friendly. Should users need to change how they organize their files, to gain access to the features of snap?

For example, today the firefox snap created $HOME/snap/firefox, along with three files in there: two empty directories (118, common) and a symlink (current -> 118). My initial impressions are below.

First, the name of the top-level directory is named after an application, rather than being called something meaningful to a user. What has been snapped? Are we talking *oh, snap*? Fingers snapping? Twigs? Camera shutters? I don't mean to criticize the name of the project, but by putting that name as a directory in $HOME, these are the questions a user might have. Particularly if the user doesn't know what the snap application is or does.

Second, two extra hierarchical levels adds complexity that seems
unnecessary. Why do I need to navigate through this? What organizational purpose does it serve, to offset the time it takes to use?

Third, the files created under $HOME/snap/firefox are named nothing that makes sense to a user. What is 118 anyway?

Fourth, the organization behind the files under $HOME/snap/firefox doesn't make any initial sense. Why is current a symlink? Are these files versioned somehow? Is that specific to firefox, or generic to snap?

Finally, taken together these first points make the content of $HOME/snap seem quite opaque. That conflicts with their stated purpose of being for user content.

After reading [most of] the comments on this bug, I decided to test it out. I downloaded a file, and found it in $HOME/snap/firefox/common/Downloads. This is deep enough in the hierarchy as to be effectively hidden from both shell and GUI users. How would I have known it'd be there? Why not just use $XDG_DOWNLOAD_DIR?

A symlink could be a workaround, to get rid of the 4+ levels of folders that effectively hide these files from view. If a workaround is necessary, then there is a problem. If there is a problem, then it would be inappropriate to consider the issue as a feature request.

XDG lets users have a clean $HOME, and to define what "clean" means. Standards like XDG have community/industry support. They should be respected, either by following, or by stating a clear reason to not follow. How should this be done in XGD? Or what shortcoming of XDG is being addressed?

Implementing snap as a feature of ubuntu is a rather aggressive way to change the standard. It seems to lack clear direction, in breaking XDG. It therefore appears to disrespect the community, for whom the standard works. The feeling of disrespect can be seen motivating the various tones of people posting to this bug report.

XDG effectively combines the data for all applications into one structure. Does this make sense for something compartmentalized like snap? At my distance (new snap user, linux user since kernel 1.x), the new file structure doesn't seem inherently necessary, to have compartmentalization. It seems that each compartmentalized app should be able to use the XDG directories. Why not?

Is part of the compartmentalization appr...

[S R (rmst)]

It is extremely arrogant that you didn't fix this since 2016 despite the crystal clear feedback from the community.

[Ivan (ivanperez-nfm)]

@rmst Unless I am mistaken, the developers are not being paid for creating snap and are just contributing their time. Perhaps it would be more constructive not to assign wrong-doing or to call their actions arrogant and simply to try to help by contributing code? Who makes these decisions when it comes to snap, and how can we engage in polite and constructive conversation with them?

[Ivan (ivanperez-nfm)]

@chrm Thanks!

For the record, I consider adding basic applications like calc as snaps in a default Ubuntu LTS installation a bad idea, for reasons I explain separately, and I've opened a separate bug just so that that is changed.

https://bugs.launchpad.net/ubuntu/+source/gnome-calculator/+bug/1788220

[chrm (ubuntu-one-3)]

I have not read everything here, but my understanding is that they have already decided to not fix this bug until the "epoch" feature is implemented. So contributing a fix is pointless. And according to the post from 2018-07-20 (#82) the epoch feature is still very far away.

[Gustavo Niemeyer (niemeyer)]

For the record, the epoch feature is being actively worked on and it's not that far hopefully.

You can track progress in the forum:

https://forum.snapcraft.io/t/epochs-stepped-upgrades/1757/57

[Sarah Tucker (sarahtucker)]

I have to say that #96 is bang on the money. It's basic business that you listen to customer feedback and act on it.

[Greg Bowler (greg-bowler-ubuntu)]

Has anyone used Windows 10 recently? Those "3D Objects" and "Saved Searches" folders in your home directory really add to the annoyance. Delete them and they keep on coming back. Does Snap want to make Ubuntu feel like Windows 10?

Putting anything as a named file or directory within my $HOME feels like a violation, especially as it is currently unconfigurable.

Also, hello from September 2018!

[Sam Volojiy (svolo)]

This is a major f up in the listen-to-the-customers department. No wonder snaps' have been struggling in getting market traction.

[Gustavo Niemeyer (niemeyer)]

We listen, even to harsh comments like that one.

I'm sorry that we cannot implement the exact changes you want on the exact time frames you want. Rest assured we are working hard on this project, though, and for years now we've been landing major improments like clock work. There are actually some very exciting changes coming in the following weeks, if you haven't been watching.

About traction, well.. just look at how many people come here to complain about a directory not being in their preferred location and you might extrapolate a bit. ;-)

More details about the solution and issues related to this directory name were provided in earlier comments above.

[Michael Mitchell (michael-u)]

Just started using snaps only to find this out :-(

I will be removing any snaps I installed and replacing them with debs until this is changed. I am personally very picky about what I have in my home directory as I am sure many others are too. Having the snaps folder visible in my home directory when there is nothing in there I need frequent access to is a deal breaker for me.

I look forward to using snaps once this is fixed

[Barafu-albino-cheetah (barafu-albino-cheetah)]

I only wish that the developers would clearly mark this as "won't fix" instead of promising to change it somewhere in the next decade.
Nowadays, user's home directory should be something different from what $HOME points to. The latter is for configs, autogenerated files and junk, just like it is on Windows.

[Zygmunt Krynicki (zyga)]

The bug will become fixable once the epoch feature is rolled out. It is not
that we don't want to fix it (we agreed and even Mark voiced his approval).
We are waiting for a feature that will allow us to fix this issue without
breaking existing applications.

On Wed, Sep 26, 2018 at 7:34 AM Barafu-albino-cheetah <
<email address hidden>> wrote:

> I only wish that the developers would clearly mark this as "won't fix"
> instead of promising to change it somewhere in the next decade.
> Nowadays, user's home directory should be something different from what
> $HOME points to. The latter is for configs, autogenerated files and junk,
> just like it is on Windows.
>
> --
> You received this bug notification because you are a member of Snappy
> Developers, which is subscribed to snapd in Ubuntu.
> Matching subscriptions: xxx-bugs-on-snapd
> https://bugs.launchpad.net/bugs/1575053
>
> Title:
> Please move the "$HOME/snap" directory to a less obtrusive location
>
> To manage notifications about this bug go to:
> https://bugs.launchpad.net/snapd/+bug/1575053/+subscriptions
>

[Gustavo Niemeyer (niemeyer)]

That's not the only concern, Zygmunt. We also need to design what we'll move towards when it actually happens. As was detailed much earlier in this thread, there are considerations about both the kind of content that is inside those directories (which isn't something that typically goes hidden), and also in terms of what we'll move towards if we're not hiding it.

There is another feature in development as well that will make it easier for applications to safely read/write content anywhere else. If that works well, it will influence the direction we go here.

So, once more, we're aware that this is an important personal preference issue to some of you, but please realize that creating directories in $HOME for user content isn't novel, and if you're using the Ubuntu desktop you do have other entries there which were automatically created already. We understand the desire of being able to change that directory somewhere else, but for reasons there were outlined earlier (e.g. confinement), this isn't as straightforward as it sounds. It's also quite obviously not a priority for us either given everything else we're doing right now on this project.

Trust me when I say we would like to see this improved as well. The difference is that we're even more keen on seeing other major features landing.

[Iván Pérez (ivan.perez-keera.es)]

@ziga and @niemeyer, thanks for explaining again that you will address it.

I just want to address two things quickly.

@niemeyer: "this is an important personal preference issue to some of you,"

Calling this a "personal preference" degrades it to something that people want, where in this case this could arguably be called, more universally, a bad decision (and I say "more" understanding that it may not be 100% absolute). That directory contains a lot of information that is irrelevant for most users. For them, that's noise. While people tolerate noise at different levels, nobody appreciates having files they'll never use mixed with their own important files. It's part of the reason why dot files are hidden by default and most people are happy about this. I'd like to see how many people who do not work in the development of snap or snap apps prefer to have that directory there, visible, all the time.

@niemeyer: "but please realize that creating directories in $HOME for user content isn't novel"

I believe this is a very incorrect line of argumentation. Your position is "others have done it too". This is not an excuse. Also they have done it differently.

Creating directories in $HOME that are not hidden is a big no-no everywhere. The rare exceptions are (GNOME's) user dirs (e.g., Videos, Documents), which people have requested to move to less intrusive locations, and can be configured accordingly. Other exceptions include Eclipse Workspaces, Virtualbox VMs, etc. All configurable, all for *user-created* content. None of them are meant to store configuration files.

Other than that, the trend has been towards having a cleaner home with less stuff and more organized. These days, even creating a $HOME/.snap dir could be frowned upon. Instead, $HOME/.config/snap might be seen as more appropriate.

[Gustavo Niemeyer (niemeyer)]

> I believe this is a very incorrect line of argumentation. Your position is "others have done it too". This is not an excuse. Also they have done it differently.

This whole thread is about consistency and common practices, Ivàn. Consistency and common practices for the placement of a single directory. No matter how passioned you are about this subject, that's still what it is.

[Iván Pérez (ivan.perez-keera.es)]

@niemeyer Well, yes and no.

First is that there can exist measures of better and worse that respond to how humans process information. We may not want or be able to use them, but they exist and they are meaningful.

Second, and more importantly, the snap directory does not contain only user-created content. I just opened gnome-calculator in the latest Ubuntu, and that created the snap directory in it. Inside, I get current, current/199, current/222, current/238, current/common, and a symbolic link. These are not files I created. My first thought when I see this is "WTF!" (What are These Files!!!). This is not user-created comment, and it's meaningless to me.

Also, even if we only base the decision on consistency and common practices, as I just tried to explain, having a directory not hidden with a fixed name in the home directory is not a common practice. If you refer to directories such as Videos and Documents, then these have a different purpose, meaningful names, and they are configurable. If you refer to other exceptions in which those directories include configuration files (which I think you don't), then I suspect these are very rare. I cannot really think of any. Perhaps you could explain one case in which this happens, is accepted by the community, and could support having snap there in plain sight?

Also, I would appreciate it if we could keep this focused on the discussion, and not the person. I may be passionate or not, you do not know me, but I've referred/discussed your arguments, not you, and I ask you to do the same.

[Gustavo Niemeyer (niemeyer)]

> having a directory not hidden with a fixed name in the home directory is not a common practice.

The vast majority of Ubuntu users in the desktop have directories named similar to "Video", "Pictures", "Documents", "Downloads", "Music", etc there, which means that in fact this is a common practice, and a very well established one at that. Claiming otherwise, and repeatedly so, washes out the better arguments.

The better argument is that yes, the snap directory is a bit different, because it deals with confinement of applications that cannot write elsewhere, and yes it currently uses a technical organization that is unlike other cases for that same reason, and yes, this organization is not optimal for users which is why this issue is still open and not closed, and yes, we also want to improve it, and yes we have been working in other priorities non-stop for years now because we felt these were more important for the survival of the project.

> Also, I would appreciate it if we could keep this focused on the discussion, and not the person.

I would actually appreciate if sometimes there was some consideration of the fact there are reasonable people on the other side.

Have a great day everyone, and sorry for the noise in your inboxes.

[Viktoria Nemkin (nemkin)]

> The vast majority of Ubuntu users in the desktop have directories named similar to "Video", "Pictures", "Documents", "Downloads", "Music", etc there, which means that in fact this is a common practice, and a very well established one at that. Claiming otherwise, and repeatedly so, washes out the better arguments.

Those directories can be customized. They can be renamed, moved or deleted completely. In order to do so you need to edit ${HOME}/.config/user-dirs.dirs .

For example, mine looks like this right now:

XDG_DESKTOP_DIR="$HOME/Desktop"
XDG_DOWNLOAD_DIR="$HOME/Downloads"
XDG_DOCUMENTS_DIR="$HOME/Data"

I removed the unnecessary directories and renamed one to better reflect the type of files I am storing in them. I wish snapd would offer a similar way to configure the snap directory location.

I am happy the developers have responded to the concerns in this thread and I hope this issue will be fixed once the feature we are waiting for is completed.

[Ernst Rohlicek jun. (ernst-rohlicek)]

I can only second what Viktora has suggested and stated.

[yak mandango (yakmandango)]

How does the snap team feel about snap following the XDG standard for files currently under $HOME/snap? Should snap keep files in those XDG directories (e.g. XDG_DOCUMENTS_DIR="$HOME/Documents")? Could it, even? Or if it shouldn't or couldn't, why not?

[Apollonaute (arn-demay)]

"Workaround" works fine!

Nice job. But clearly not "Unix" style...

[alex barton (alxbrtn)]

I propose if this issue isn't rectified reasonably soon, we fork and make the desired changes.

My vote for name is "ohsnap".

[Zygmunt Krynicki (zyga)]

> Wiadomość napisana przez alex barton <email address hidden> w dniu 28.09.2018, o godz. 06:12:
>
> I propose if this issue isn't rectified reasonably soon, we fork and
> make the desired changes.
>
> My vote for name is "ohsnap”.

Or you can just try to contribute to the discussion and coding upstream. Then we can discuss what needs to happen to properly represent the snap directory and the files therein in a way that people can migrate to. We are all in #snappy on freenode and on forum.snapcraft.io <http://forum.snapcraft.io/>, the code is on github.com/snapcore/snapd so please contribute there.

Best regards
ZK

[Iván Pérez (ivan.perez-keera.es)]

@alxbrtn As much as I hate that this bug is present, forking a project only makes their efforts potentially less valuable and creates an unnecessary competition. It's best if you contribute to the snap project to make it better, like @zyga suggests.

Please, avoid forks just because a feature is missing or you don't like it.

[Theofrastos Mantadelis (igognito)]

I have a related to this bug. Perhaps it should be a different bug but I'm not sure.

When I try to open/save a file with some apps: chromium, gimp, and others (I think the ones that appear in the snap folder)
It seems that the home folder button on the dialog directs me in the snap home folder of the application and not at my home folder.

Any Idea how to fix that?

ps: you can see at the attached image

Thank you

[LKV (likivik)]

Theofrastos Mantadelis (igognito), what you are experiencing is not a bug, it's a feature. It's related to how snaps are restricted in acess to the system (confinement). Please see:https://snapcraft.io/blog/demystifying-snap-confinement

[Frank Quinn (fquinner)]

The one nice thing about this is that it gives me a list of applications that use snap so that I can remove them, disable snap and use flatpak instead. Which I just did.

Will keep an eye and consider returning to Snap if this is fixed.

[Mike (eqx.tfl)]

What a terrible idea to put this folder at this location. I am removing snap too.

[Rainer Defender (materialdefender2306)]

This bug was opened in April of 2016, two and a half years ago. It was also assigned to some "shakedown" and the number of "people affected" has gone up. People have also gotten so angry about it that they've removed Snap from their systems altogether, so it's clearly an emotional subject.

Would it be possible for a team member of the project to give an estimate as to when this bug is at least going to be moved out of the wishlist?

[Jonathan Hernandez (jonherbla)]

I am removing snap too and I will start using flatpak

[S Rosbly (rosbly)]

I installed the IntelliJ snap but removed it because of this behavior.

In my case, the ~/snap folder only contains application data + I don't intend to save any personal file there. Therefore it has not its place in my home dir.

[Piotr Żurek (piotrek.zurek)]

I tried to remove snap due to this behaviour (and that gnome-calculator, system monitor doubling insanity) so rushed a little and removed all the snaps before. Then realized that upgrading to 18.10 automatically and forcefully upgraded also my lxd package to snap and migrated my containers with it. So removing lxd snap also removed all my migrated containers from /var/snap/lxd/common/lxd/storage-pools/lxdpool. Nice move! It's not so smart flushing user data with a deinstallation of an application is it? It somehow left irrelevant and probably randomly chosen image of fresh centos7 image and one old and not useful centos6 snapshot.

Then I found this issue and many more that are snaps (like no automatically added bash completion and usually no option to have man pages for snap installed binaries (lxd does not even have one inside the snap).

The snap is NOT ready as a product, yet it's pushed down everyone's throats. I will really miss lxd as it was really great product but not as a snap (and debs are already deprecated, also no lxd debs in cosmic).

I doubt You will miss me, but I and many others will miss Ubuntu due to things like that.

[Gustavo Niemeyer (niemeyer)]

Snapshots, which is mostly finished by now, will allow keeping data past the removal of the snap itself. That said, it will only hold the data saved for some time. The design applied there is a trade off between leaving data behind forever, and risking removing data unintendedly as you reported.

Support for man pages shipped inside snaps is in the roadmap.

Bash completion works and should work automatically, though. If it doesn't please file a bug for it if you have the time.

It's just a shame you feel the need to be harsh instead of collaborating towards getting your problems fixed. Ubuntu was always developed in an iterative process, and with the collaboration of the community, and snapd is no different. We're very proud of where we got so far, yet there are many improvements and features to come still. That will happen with or without you, but it's always better to work together.

Have fun and take it easy, no matter where you go.

[Iván Pérez (ivan.perez-keera.es)]

@niemeyer I agree with you that there is no need to be harsh and, as an open source developer and maintainer myself, getting help from the community is greatly appreciated. Attacks are very demotivating.

Unfortunately, I also agree with the general sentiment around here: snap simply is not ready as a product to replace core technology in Ubuntu LTS and the responsible thing would be to pull it out for now.

The work that we do daily with Ubuntu is also important. You can encourage filing issues, sending patches and getting help from the community. People will respect snap and all the developers' efforts more if they also acknowledge its limitations and understand the importance of the work that we do and why we cannot depend on technology that is not ready yet.

I strongly suggest that the snap team takes this seriously, voluntarily contacts whoever needs to change Ubuntu LTS to pull snap out from the default installation for now.

As a system maintainer and a sufferer of this package maintenance madness that surrounds not just Ubuntu but many programming languages, I'd be happy to contribute by listing the features that apt has and snap doesn't that I find make apt more robust (for now).

[Gustavo Niemeyer (niemeyer)]

The picture might not be completely clear if you haven't been watching, so let me help:

- We have snaps by default in Ubuntu for years now
- There are thousands of snaps published
- There are more than 100 thousand snap installs per day
- There are more than 3 million new snap installs a month
- They are being used in 40+ Linux distributions
- The developers that do snaps also worked on Synaptic, APT, APT-RPM, RPM, etc

Improvements and features are constantly landing, and many more are coming, but this is as production as it gets.

[Piotr Żurek (piotrek.zurek)]

My latest statement could be called "harsh" I guess. Sorry for that but as really like Ubuntu things like this made me look for viable long-term alternatives (which I never considered since Dapper Drake until now). I wouldn't post here probably if I didn't care for Ubuntu so I'm going to stay with You for longer in hope the development will eventually fill the gaps.

That said mentioned lxd behaviour is just bad UX decision in my opinion. Either removing lxd snap should at least warn and allow manual cancelling further action altogether or just leave user data (in this case all created containers/storage pools) intact (still with ability to display a warning).
It's totally different behaviour from regular server applications installed from deb packages that when removed just leave data in /var/lib or whereever they keep their data in (when we remove such package the dpkg just displays a warning about inability to delete dirs in ie. /var/lib/appname due to not being empty (rightfully so as it apparenly contain files that didn't came with the deb package in the first place so it's probably user data which should be treated with care).

I still think snap is NOT ready product yet. I hope it will be in time for next LTS though.

[Piotr Żurek (piotrek.zurek)]

I started to see if I can help and took a read at snap bugs list at first to not report duplicates.
I thought only server applications like lxd are affected by this design but it seems "regular" desktop snaps that keep data in home snap dir do the same: https://bugs.launchpad.net/ubuntu/+source/snapd/+bug/1644561 . This is by design so not easy to fix if at all possible at this stage (probably that's also why it is in "triaged" state since 2016. Too bad nobody seems to care for this bug also (only 1 subscriber until I found it, subscribed).

Bash autocompletion weirdly seems to work after reinstalling snap and lxd snap from scratch, it didn't when automigrated during 18.04>18.10 upgrade.

Man pages really come in handy on servers so I look forward for this (I only hope it
won't be ommited by snap packages maintainers and will be added where applicable once functionality is available).

[Gustavo Niemeyer (niemeyer)]

> This is by design so not easy to fix if at all possible at this stage

It is by design, but as I said the solution not only is possible, but is elegant, and is almost done.

The foundations of snapshots is done and is landing (https://github.com/snapcore/snapd/pull/5955). In the coming weeks, we'll make that foundation automatically create a snapshot when a snap is removed.

Proper man page support is also in the roadmap.

[Silvio Bierman (sbierman)]

Reading the above gives little confidence this weird design decision will be reverted anytime soon or at all. I just did "apt purge snapd" to completely remove Snap from my 18.10 desktop. Things are now back to how I want them. I just had to install the regular gnome-calculator.

[Piotr Żurek (piotrek.zurek)]

Hmm. it's a solution that fixes that different than everywhere else by-design behaviour -->

--> As I understand the idea is to have a system that hopefully won't grow/clutter itself by installing/uninstalling applications as system is used in time (like Windows still does and Linux to some extent (albeit it's very easy maintainable in Linux) too - so it will not require reinstallation from scratch from time to time to achieve acceptable performance? Also possible security benefits of not leaving unmanaged data behind. Brave, but I'm not sure it's really worth it.

I am likely to accept and adapt to such a workflow but then these questions arise:
1. Assuming that snap itself comes usualy as a deb package it won't delete the data (including snapshots) it created itself during it's use, would it? (No other sane deb-installed service would AFAIK as I pointed earlier.)

2. Similarly to ie. Android when application is removed all the data from application's dir under snap home dir is also deleted (soon(?) to leave an always done on-remove-snapshot). I think I would still like to be always asked by snap commands (text UI, graphical UI) if I really want to remove some app. Game saves, edited photos, music, databases of apps that are strictly confined and not using home dir access (for whatever reason) to place their run-time created files come to mind (these would most likely be also lost in Android unless backed up using some Google's backup APIs or saved to shared space/"sdcard").

To not to be off-topic - /home/snap is still ugly as hell, wasn't it an option to become /home/.snap in the begining of a project?

[Kate McKenzie (alayarah)]

This is a deal breaker for me. I've purged snap and won't be using it until this is fixed. I'm glad I found out about this before upgrading to 18.10.

[kosheo (kosheo)]

This is indeed a very serious issue and definitely should not be a 'wishlist'.

I'm not aware of any other application that respects user so little that it forces you having folder with hard coded name in your home from the moment installation and forever. It pollutes everything: file manager, command line, search etc.

If you using GUI file manager it is also extremely easy to remove or move this folder with accidental mouse drag and only notice it when half of your apps stop working correctly.

In fact, when I first noticed snap folder I just removed it as I though it was some cache that wasn't cleared by the snappy...

I understand that it may be quite difficult to fix, but I think this issue deserves more attention.

[Anton (feenstra)]

a system software management tool that cannot be configured to avoid interfering with users' own (home!) directory layout, should not be used in a LTS version of a major OS like Ubuntu! This MUST first be solved, irrespective of how conceptually or practically hard/impossible it is said to be.

[Anton (feenstra)]

p.s., I've just apt-remove-d snapd, it isn't even essential... sigh...

[Wolfgang (wolfgang-v)]

I also cannot understand how creating an intrusive directory that cannot be moved in a users home directory is acceptable.

Hoping for a fix coming soon as a software I have to use frequently is only available on Ubuntu through snap installation at the moment. To currently circumvent snap I am using the windows version of the application in a virtualbox image. Would be nice to run a snap (that does not create a snap directory in my home directory).

[Salvador Diaz (salvadordiaz)]

I've been using ubuntu since its first version and I've put up with some unfortunate decisions through all those releases because trade-offs always seemed to be worth it, and not once I've been tempted to be rude to ubuntu developers.

That changed today when I finally decided to investigate what was in that ~/snap folder and why it was constantly reappearing in my home folder and I found this bug report. I get that you made some wrong assumptions and now it's hard to change the initial design, but I just don't get how you can openly talk down to seriously frustrated users and downplay the issue for more than two years.

Anyway... for those of you wondering how to get rid of these folders, just remove snap:

sudo apt-get remove --purge snapd gnome-software-plugin-snap

If you're on a fresh ubuntu 18.10 install, you might want to install the non-snap versions of the couple of system apps that were installed by default using snap:

sudo apt-get install gnome-system-monitor gnome-calculator

[Carl Best (cbest786)]

A lot of discussion about moving the directory to .snap or .local. I would be happy is for all that is sacred if they are not going to hide it since data can be stored there PLEASE just capitalize it like every other visible folder in my home folder:

\Desktop
\Documents
\Downloads
\Music
\Pictures
\Public
\Snap
\Templates
\Videos

Whats so hard about being consistent so it does not immediately make me zero in on it and go ... one ... and only one of these is not like the other one.

\Desktop
\Documents
\Downloads
\Music
\Pictures
\Public
\snap <------------
\Templates
\Videos

[Daniel Stoyanov (dankh)]

I went the sudo apt remove way. I'm like many Ubuntu users, creature of habits and obsessions. The $HOME is really a home for me, I like it tidy in clean. I can't stand somebody putting a shelf in the middle of my room and "deal with it" ... I love Ubuntu so please remove this shelf off my room and put it in the closet.

[Gustavo Niemeyer (niemeyer)]

Hi Carl,

This is likely what we will do indeed, as it's a nice partner to the other standard options already there, is language-agnostic, and thus easier to handle on the confinement sense. We'll also clean it up a bit on the way, by stashing the non-current revisions in a better place.

[[e-mail] (deckoff)]

I hope this is some kind of a tasteless joke.... If you really, really, really insist on having a visible folder inside the home dir, you can just create a ln - Snap linking to .snap (or whatever the real folder would be). I wont repeat everyone, but totally agree with them

[Carl Best (cbest786)]

Not really a joke.

Its the more reasonable approach. As someone already stated its not just configuration in the snap directory ... snap apps also seem (whether I agree with whether the SHOULD) to store data in the snap directory. My Videos are data. My Downloads are data. My Documents are data. Why cant snap apps store data in the Snap directory. Now an even MORE reasonable variant would be to put CONFIGURATION in .snap/<AppName> and DATA in Snap/<AppName>. Apps that don't need to store data .... like the darn Calculator (come on .... please .... its a calculator if it needs temp files use /tmp) can just put config in .snap and not create the Snap directory at all. It IS a little ridiculous that every time i start the calculator it get a snap directory.

Now ... don't get me wrong ... in a more ideal world (which I almost never get to live in in the not quite 30 years I have been writing software) you would put all data in the existing data directories where grandma knows where it is already .... and put config in .snap/<AppName> and call it a day. We, however, do not live in an ideal world and should, when POSSIBLE, compromise. For some people compromise seems to be a dirty word.

------------------------
When its a matter or principle you stand like an oak. When its a matter of style, bend like a willow. The problem is .... when you think EVERYTHING is principle.

[Davide (davide-cester)]

@Carl: "Why cant snap apps store data in the Snap directory."
Because it's not intuitive, it's not descriptive, it's not configurable. My Videos contains videos, Snap contains... what? I can delete My Videos and move my videos, but I can't delete Snap directory (unless I totally stop using snap).

My girlfriend recently moved to Ubuntu from another system, her second question was "what is that folder in my home? I never installed any application named Snap". Sorry, it's just a bad choice. I can accept if developers say "we don't have the resources to change it" or even "we don't care" but "why can't you all forget your standards and best practices" does not sound totally right to me...

[LN (lninja)]

What a shame. Purged snap until the issue is fixed.

[Karl Damgaard Asmussen (everything-narrative)]

Seconding #150, I'm not using snap until this is fixed. The explanations of whys and wherefores indicate to me that snap as a software development project is beset by bad development practices.

[Stephan Burkhalter (stephbur)]

Also removed snapd. I cannot believe this is still a thing after almost 3 years of this bug being reported. I troubles me very much, that the devs do not seem to take this issue seriously (enough). I hope developers are going to reconsider putting everything in .snap.

I really don't understand why one should put user data in the snap directory. What if I have a project that uses snap AppFoo and AppBar? Then I will find my files in ~/snap/AppFoo/data and ~/snap/AppBar/data instead of together in ~/MyProject?

[Viktoria Nemkin (nemkin)]

Also removed snapd. I cannot believe this package is by default part of the current LTS installation of Ubuntu.

[Viktoria Nemkin (nemkin)]

As it stands right now, this bug has the most heat from all snapd bugs, more than 3 times as much as the next one:

https://bugs.launchpad.net/ubuntu/+source/snapd/+bugs?orderby=-heat&start=0

Yet, it's marked as 'Wishlist' and has been untouched for 3 years.

[Jalon Funk (francescohickle15)]

@nemkin this "bug" touches core snap architecture. Fixing it will need a lot of work and at the end it's pure aesthetics.

[Viktoria Nemkin (nemkin)]

@francescohickle15 People care about aesthetics. Many of them, including me, uninstall snap because of this. You are right, this is not a bug. This is bad design at the core of snap's architecture.

[kosheo (kosheo)]

@francescohickle15, this is not "pure aesthetics".

Creating random folder in user's home directly, without user explicitly requesting it is just bad design. Not giving user any option to remove/move or even rename this folder is a horrible design choice and has nothing to do with aesthetics. As many people here mentioned is has multitude of negative consequences and I'm not sure why Snap developers keep ignoring this critical issue while hiding behind "it is hard to fix and we like it this way" argument.

[Gustavo Niemeyer (niemeyer)]

Viktoria,

We have been working non-stop on snapd over those three years, including features that will improve the situation for this folder. The fact it is marked as Wishlist reflects more on the fact nothing is in fact broken, other than you and me would both like to have a nicer folder structure.

The fact this bug has the most heat also reflects on how easy it is to have an opinion about it
(https://en.wikipedia.org/wiki/Law_of_triviality).

Don't get me wrong, though. We will do better here for sure.

[kosheo (kosheo)]

I don't think it is fair to attribute popularity of this bug to the law of triviality.
IMO it generates so much heat because it is directly visible to the end user and also affects everyone, regardless of what snaps you use.

It is nice to hear that there are still plans to fix this though.

[Mark Hamblin (5-mark-8)]

May I humbly request this bug be raised up the priority list to be fixed. My linux knowledge is small in comparison to many of the folks here,.. but it be gratefully appreciated if this issue could be resolved, as 'df' listings are loosing their impact and clarity as they are being cluttered by the inclusion of 'snaps'.
many tx

[Justin Roberts (tjten5500)]

I agree that this is poor design and will be uninstalling snap until this is fixed.

[Alex Meakins (cnlpepper)]

Creating a random first class folder in my home directory is intensely irritating, it is just junk that gets in the way of tab completion. I have no need to enter that folder every day, quite unlike every other non-hidden folder in my home directory. It should simply not be there. This can't take more than a few minutes to fix surely?

I'm reading the response from the snap dev with considerable incredulity. A developer working on a public facing project, frankly insulting users making a serious request that about a behaviour that is undesired.

Snap is a solution seeking a problem. All it is doing is complicating system administration for minor gain. Tried doing a "df -h" lately? It's now full of 10s of loop back entries, none of which are useful, all stupid snap mounts. Given the intention to expand usage this is going to scale until the basic disk space command "df -h" (among others) will be unusable without filtering the results.

I think perhaps less arrogance and more looking at the wider user impact of design decision would be more appropriate. You want this to be a success, start by NOT irritating your users.

[Iván Pérez (ivan.perez-keera.es)]

Removing snap here too. I've said this before: I think snap should not be installed by default in Ubuntu LTS. The calculator should not be a snap. It takes way too much space and takes too long to start.

People can install snap if they want: the software manager is trivial to use, even computer-illiterate users can use it.

Ubuntu could even offer to install snapd when someone tries to install a snap, and everyone would be happy.

[Oliver Grawert (ogra)]

> It takes way too much space

Snap packages are by a *significant amount* smaller than their deb packaged equivalent, they are shipped as highly compressed read-only squashfs files that do not get unpacked but loop mounted on the host. typically a snap only uses about 30% of disk-space compared to the same amount of files/software shipped as deb packages. i'm not sure who came up with the claim that snaps are bigger, but this is definitely a completely wrong accusation.

[Iván Pérez (ivan.perez-keera.es)]

The standard installation of snap, with no custom snap apps installed other than what Ubuntu installs by default, takes 1.6GB of hard disk on my machine.

Snaps themselves may be smaller to download, but keeping these things installed takes more space.

[Iván Pérez (ivan.perez-keera.es)]

After purging snap completely, I just tried to install just gnome-calculator with snap.

$ sudo aptitude install snapd
(some output)

$ snap install gnome-calculator
2019-01-15T09:32:40-05:00 INFO Waiting for restart...
Automatically connect eligible plugs and slots of snap "gnome-calculator"

$ sudo du -sh /snap
489M /snap/

If you run the calculator, then this happens:

$ sudo du -sh /snap/
1.1G /snap/

Is this really lighter than installing it with apt-get?

$ apt-cache --no-all-versions show gnome-calculator | grep '^Size: '
Size: 253432

Unless I am very much mistaken, those are bytes.

[Iván Pérez (ivan.perez-keera.es)]

And, just for completion:

$ sudo du -sh /snap/gnome-calculator/
7.3M /snap/gnome-calculator/

Which is, still, more than the space that the gnome-calculator takes when unpacked from the deb.

[Oliver Grawert (ogra)]

you are measuring the content of a mount point, not the on-disk footprint...

feel free to go on discussing on https://forum.snapcraft.io, this is off-topic for this already way too noisy bug ...

[Oliver Lorton (olorton)]

I'm in the process of switching away from MacOS to a Linux DE and I've created a lauchpad account just to register my frustration at this bug. I've just tried out snaps for the first time and after installing pycharm-professional have discovered the snaps folder contains nothing but config data. Well, actually it just seems to have a version numbered folder symlinked to a 'current' folder. This should be stored according to the XDG Base Directory Specification

$ du -s ~/snap
16 /home/oliver/snap

My feeling is that this issue should have been tackled when it was raised in 2016. Specifically, the OP's suggestion that _still_ stands: Snap package developers should be encouraged to store user data according to the XDG Base Directory Specification.

However, it's 2019 now and there are apparently over 1000 snaps in the wild. I wouldn't want the task of fixing this. After reading this thread it's also apparent that devs see this as a trivial issue, marking it as 'Whishlist'. So, like others here my only conclusion is that I'll have to purge the snap environment from my system.

I'm so disappointed that the snap system is flawed in this way and is becoming harder to move away from with every snap package that is created.

[Gustavo Niemeyer (niemeyer)]

The fix for one snap or ten thousand is exactly the same, as we're addressing this inside snapd proper. No snaps will need to change.

[Pavel Dolinin (pavel-dolinin)]

Hi
Please make it configurable.
Thanks,
Pavel

[Yasin Zaehringer (yasin.zaehringer)]

Hi all,

I see the reasoning behind #40, it is about having an isolated interface between snaps and the normal world. But making the directory configurable shouldn't pose a problem at all. My favorite long term solution is that the folder lives somewhere else (maybe /snap/interchange/<user>/) similar to /media and file managers have a shortcut in the side bar.

Best,
Yasin

[iBART (mogio)]

It "affects" me too.

[Daniel Giguere (daniel.gig)]

Create an account just to say it affect me too.

Purged snap until it's fixed.

[Daniel Giguere (daniel.gig)]

Do note that this bugs as the most heat of all snapd bugs, more than 4 times the value of second next highest heat bug. This should make it a priority.

[Alex Corbin (comicsads)]

Just made/realized I had a launchpad account for this. I love snapd but I'm tired of seeing the ~/snap directory pop up so much that I added a line to my bashrc to notify me if it shows up again. I'll likely be reinstalling snaps once this gets fixed, but I do want to say one thing to the developers. when a problem has 5 times as much "heat" as the next largest complaint, your userbase probably cares a lot about it, and it comes off as pretty disrespectful for you to just pass it off as an example of the Law of triviality. IMO, this should have been done soon after this bug was posted, and symlinks of some kind for each snaps download folders and such.
That being said, I have barely looked at the snap code at all, and would like to ask the developers why just grepping for every @{HOME}/snap and replacing it with @{HOME}/.snap wouldn't solve the problem? What containerization would be broken if you found and changed every reference to the snap folder?

[luarocks (luarocks)]

+1. Purged snap until it's fixed!

[Robert Kujawa (kujaw)]

Also had to purge it, since this bug has a lot of people affected and looks like maintainers don't give a freak. Luckily, there are other easier and unaggresive ways to install software I need without cluttering the system.

[Thiago Madureira Braga (thmb)]

Purged snap until it's fixed! Snap seems to be a great idea but I don't want it trash my home.

[Zygmunt Krynicki (zyga)]

I am working on a bit of refactoring of of the snapd execution layer that will culminate in the ability to fix this bug. I'm very much interested in fixing it.

For everyone interested: it is not easy to just move the directory or to make it configurable. The technical reasons are pretty long and complex so I will skip listing them here.

The work I'm doing will allow us to explore the following:

- move the $HOME/snap directory to a hidden directory (e.g. to $HOME/.snap)
- preserve compatibility with all existing snap packages
- allow us to create a view of $HOME/.snap that is optional, can be provided under any name (e.g. $HOME/Snaps or "$HOME/Fancy Futuristic Packages", and one that has much more interesting contents than $HOME/snap does today. Lastly it will allow us to engage with the developers to shape how they present snap files to users.

I'm not ready to commit to any timelines yet. I just want to let everyone know this is something we are working towards.

[Michael Walz (serpedon)]

+1 for fixing this

In the meantime, I purged everything snap-related except pdftk which I use occasionally. For pdftk, I wrote a small wrapper which (except one symlink) removes the otherwise empty folder hierarchy $HOME/snap automatically after using pdftk.

[Niko Wicaksono (wicaksono)]

+1 flatpak is better for this time.

[Joe (cutty)]

+1

When I finally had to use snap a year or so ago I installed a few other applications. I had to fix a .desktop file in one of the snaps. Got confused why I couldn't edit the offending file as root, realized they were mounted read-only images.

A few week later saw $HOME/snap and figured it was just left over from my previous investigation since genuine Linux programs [0] usually don't do things like that and nuked it. Realized my mistake when the snap programs all lost their data.

This is one of those things that confused me and could scare less experienced users into thinking it's some sort of virus or nefarious actor.

[0]: A few current offenders include: Silicon Labs Simplicity Studio, ST Micro STM32CubeMX, Xilinx Vivado; you see the trend. There are other these are just the recent ones.

[bram lagerweij (bramlagerweij16)]

+1

I solved it (for now) by changing settings in Nautilus.
But this ain't a fundamental solution.

>>> echo snap >> ~/.hidden

[ajaest (ajaest)]

I used snap for the first time and I loved it. Then, a couple of days later, I discovered the snap folder at home, such a terrible mistake after so much good engineering.

I humbly think that it shouldn't be so difficult to at least patch snap to use by default $HOME/snap folder for backwards compatibility, but allow new installations to use a different folder (maybe using env variables?).

That would suffice for me, as reinstalling all packages is not so painful. I the meantime, I will purge snap.

[David Norris (dvnrrs)]

I removed snap because of this issue and because of the developer responses. This is really a very basic good-neighbor policy that all software should respect - and by and large, almost all other software I've used in the last decade does. There is in my mind no justifiable excuse for putting off a fix for more than 3 years, even in the face of clear and very respectful user feedback about its poor reception. For me this falls in the same category as adware and annoying third party "update check" background apps like Oracle's Java Update.

[Jam Risser (codejamninja)]

I would write a long complaint about this too, but everyone else already has. Please allow the snap folder to be moved so I can hide it.

[yak mandango (yakmandango)]

@zyga: In your last comment in April, you mentioned a refactor would let $HOME/snap be moved to $HOME/.snap instead. You also mentioned creating "views" of the new .snap directory.

You didn't mention the possibility of using XDG paths, or making the path configurable per system or per user. Would either of those be possible after the refactor?

[Zygmunt Krynicki (zyga)]

> On 21 Jul 2019, at 03:28, yak mandango <email address hidden> wrote:
>
> @zyga: In your last comment in April, you mentioned a refactor would let
> $HOME/snap be moved to $HOME/.snap instead. You also mentioned creating
> "views" of the new .snap directory.
>
> You didn't mention the possibility of using XDG paths, or making the
> path configurable per system or per user. Would either of those be
> possible after the refactor?

Using XDG paths is hard because they don’t map to the concept of the snap directory. Let me explain where I am going with the idea of the snap folder.

The folder itself will remain a special folder with a constant name. The name will just be prefixed with dot to hide it. The name must be constant for a large number of reasons: it is present in global (not per user) confinement profiles, it is accessed by snapd on behalf of a logged out user, it is persistently mapped into other mount namespaces. All of those make it infeasible to both have per-user variability and even changes while the user is logged in.

The contents of the future $HOME/.snap folder (note the leading dot) would largely remain as the public $HOME/snap folder today. It is a tree of per-revision mini-home filesystems. Those already include provisions for .cache .config and .local. Since snapd is not mandating a particular design on packaged applications we cannot constrain applications to just those locations. We cannot also shared them with typical XDG locations (that is real $HOME/.cache, for example) since that would introduce an attack vector on the host. For this reason is best if the per-snap mini-home filesystems retain their current form.

The view concept works as follows: the user can optionally mount a special file system, that is purely designed for interaction with classic side of the world (that is, it is not actively used by snap application processes but could be used by file managers and users themselves). The filesystem would expose a curated view of the per-snap data in a way which allows the snap package maintainer to design.

As a simple example: let’s say we have a photo management application called photo-manager. The application stores data in $HOME/.local/shared/photo-manager/data. When packaged as a snap that would be translated to $HOME/snap/photo-manager/common/.local/shared/photo-manager. That is already very obscure and non user friendly. The snap packager could use new syntax in the snap.yaml file, to describe how to map that path to user-friendly data. For example we could say that the only folder visible should be “Photos” and it should correspond to the long path mentioned above. When using the file manager the user could navigate to, say, $HOME/Snaps/ (or whatever name that a particular user chose to use, including localised one). Inside that directory the user would see a special filesystem that interacts with snaps to expose only the view described by snap.yaml. In our case it would be $HOME/Snaps/photo-manager/Photos. This would allow to, over time, build nice experiences for user interaction, all while maintaining compatibility with snap applications available today.

To get there we need some more pi...

[Regular User (dot.ru)]

It's 2019 and you guys haven't fixed this. I'm gonna stick with flatpak.

[Wolfgang (wolfgang-v)]

+1. Purged snap until it's fixed!

Also +1 that snap should not be part of Ubuntu LTS in its current state.

Looking forward to giving snap another shot as soon as the situation has changed. Hopefully "we will improve this situation" does not mean that the folder location will not be configurable but renamed to uppercase "Snap" still within the user home directory.

[Tobe (tobeon)]

I imagine one solution could be that the snap-framework redirects all references to $HOME/snap in developers code to $HOME/.local/{share,bin}.

[Zygmunt Krynicki (zyga)]

Yes, that's the rough plan. Right now we are leaning towards something more like $HOME/.snapdata instead of .local .config and .cache because of the fact that those are not modelled explicitly by snapd. The change will allow us to eventually make the presence of $HOME/snap optional, under any name, with much better contents than what we have right now.

[David Norris (dvnrrs)]

@zyga, given the very high heat of this issue and the number of users who purged snap because of it, would you consider a short term patch to allow people to rename/move their snap directory? I can certainly understand wanting to improve the overall storage layout and to craft a really elegant long term solution. But over 2 years have passed, and it doesn't sound like such a solution will be ready for a while longer. I'm certain it would make a lot of people very happy if the developers provided a temporary workaround. Even if it were a hack and even if it caused potential compatibility issues which users would have to resolve themselves. Just my two cents - it makes me sad to see a promising project lose so much "market share" due to something as simple as this.

[Zygmunt Krynicki (zyga)]

@dvnrrs unfortunately that's the hardest part of the change

We are going to be sprinting next week and I've added this topic to the agenda. I'd like to consider a plan of moving ~/snap to ~/.snapdata. Unfortunately any such move is extremely complex as it involves running systems, data migration for users who are not logged in but have encrypted or remote home directory, semantics for rollback of snapd/core which brings older snapd and old semantics, security review and a host of other considerations.

The part where the user can give it a custom name only comes after that, where a new FUSE filesystem would be mounted in user session, exposing a subset of data from $HOME/.snapdata to $HOME/Snap/$SNAP_NAME/... The magic is that at this stage "Snap" is arbitrary because it no longer matters at runtime. Applications would use $HOME/.snapdata/ automatically.

So unfortunately this bug is as hard as it was before. The thing that has improved is the overall health of the mount code so that we have more trust in our abilities to develop changes here, reliably.

[Wolfgang (wolfgang-v)]

@zyga Still following this thread in the hope of a fix some time. Thank you very much for the insights and this incredible outlook. Really excited about this happening some day! Thank you.

Even a fixed .snapdata as first iteration would be an awesome improvement in my point of view.

[Sebastian (sebastian69)]

I'm also affected and annoyed by this behaviour. My home folder has a meaningful structure, as it suppose to be, and this is just unacceptable.

Unfortunately, my file manager PCManFM doesn't even support to hide listed files, so I cannot get rid of it in any way.

[Mr Aaron J Michaux (amichaux)]

Just fyi to the snap developers.

I delete the $HOME/snap directory every time I see it. I agree 100% with #2 that it's arrogant to create this directory. If I'm forced to use a snap app, like skype, I just delete the directory immediately afterwards. And I really hope that snap has no future, unless they fix this issue.

[Sergey Ponomarev (stokito)]

Why the task is marked with importance Wishlist? As for me this is even offensive to ignore this task because this is a HUGE violation of basic rules that users are expect to be followed.
In my case I have the /home directory mounted as a separate encrypted volume with very limited size.
So now I have a lot of problems because at some point the snap folder eats all the space and programs are crashed and my REALLY important personal data was lost.
Since my volume is encrypted so each time when the snap program is loaded it encrypted and decrypted and a lost performance and electricity for nothing.
Please fix this ASAP

[Sergey Ponomarev (stokito)]

For those who like me want's to move snap folder content to another partition to keep the home volume size you can mount (bind) the folder to another partition:

1. add to /etc/fstab the line
/opt/snap /home/alice/snap none bind
do not forget to replace the `alice` with you user name
2. create /opt/snap folder and move there all content from the ~/shap folder. Note that owner of the /opt/snap folder should be your user.
3. Mount everything with sudo mount -a

[C A (murfit)]

Agreed, this ignoring standards is arrogant.
Not only regarding users, but also regarding application developers that distribute via snap.
An application that messes with my visible folder structure gets immediately a negative reaction from me. In this case, the application / its developers don't even deserve that.
If it is configuration, it belongs into ".config/snap".
If it is data, it belongs into ".local/share/snap".

[Caleb (caleb-pirsquared)]

The long chain of arguments from the devs that the snap folder is different just reflects what they *want* the snap folder to be, not what it actually is. I have 10 folders inside $HOME/snap. I have no idea what content is in any of them, nor do I care about that content, nor would I ever browse it as I would Documents, Downloads, etc. It is simply junk.

I'm not upset that the software has this problem, but I'm upset that the devs have not treated the problem seriously. It's been over 3 years since the issue was raised. Every single person who installs Ubuntu runs into the "snap" folder and has no idea what it is. UX matters and this is a major UX failure. The devs of snap, in their responses here, completely disregard common sense UX due to (a) technical reasons, which despite being of clear importance do not adequately justify 3 years of not prioritizing this, (b) pedagogical beliefs about what the snap folder is/should be, which are just idealistic since that is not what the folder actually is.

Yes, I'm happy that fixing this is on the roadmap. But no, I don't think that taking 3 years so far is excusable, and I don't think this issue has been given nearly the attention it deserves. I'm sorry but renaming a folder doesn't require 3 years of work -- no matter what idealistic idea you have for the software in the long term, just disregard that for now and rename the **** folder as everyone is clearly annoyed, and it's your fault for dumping junk on them that they didn't want or need. After you rename the folder you can solve your technical issues about where snap apps can store their stuff.

[Felix Hoffmann (felix11h)]

There's not much I can add, but having only recently installed snap I'm also very surprised to have found the snap folder in my home directory. I know I can hide the folder in nautilus, but this is not the point. There have been many reasonable suggestion of where to put the folder and hope one of them can be considered and soon be implemented. Thank you.

[Mozart Petter (mokkun)]

Just here to say that this is very frustrating and the reason for me to stop using it.

[Andrew (coyotefoxtrot)]

Yeah this comment thread has been going on for years. I am new to snap and will be quickly researching other alternatives such as flatpak and traditional installs for all my snaps so I can be snap-free. I can't believe people have been trying for years to get a simple problem fixed.

[Andrew (coyotefoxtrot)]

Happy 2020

[Paweł Stołowski (stolowski)]

Please do not spam this bug report with meaningless comments. Comments under bug reports should be limited to the merit and provide extra info where info is lacking, "me too" is not really bringing anything to the discussion.
It is understood that this issue is very important for some users. Zyga invested quite some time into investigating it, commented a couple of times and gave extensive explanation about why this is not an easy change. This problem is not a bug but a design decision and since it's not breaking snapd/snaps, it has been categorized as "Wishlist"; it isn't fixed not because we ignore it, but because our hands are full with other features, and of higher priority.

We hope for your understanding.

[Ivan (copilot-language)]

Sorry, but no.

As developers and apps creators, snaps are being pushed on us everywhere and cornering us into change practices and toolchains. This is a lot of time that we have to invest, not knowing whether it's going to pay off, because some company made a decision to vouch for yet another app distribution standard that sacrificed too many of the benefits we had way before it was ready.

It's perfectly reasonable that people let you know that something, while being functionally smaller in your opinion, is a decisive aspect for them.

It snap is based on a bad design, then the bug is much more serious than it seems because the design is broken, and we cannot rely on it.

[Kyle Barbour (kylebarbour)]

Given snap's many poor design choices, I was delighted to find that

$ sudo apt autoremove --purge snapd

had no disadvantages for me, and I recommend it highly to anyone who is able to avoid snap in their ecosystem. In addition to solving this home directory issue, it eliminates some of snap's other intentional clutter, such as bloating `df` and `cat /proc/partitions` with garbage.

Regarding unnecessary comments, I'm glad to see people standing up for themselves. Since the devteam's choices don't respect us, I think we have every right to return the favor. It seems to me that after 4 years, continuing to annoy them is one of the few options available to those who can't avoid snap altogether.

[Wolfgang (wolfgang-v)]

@stolowski Although it does not break snapd/snaps this design decision goes against well established standards and practices and causes issues for users in the host environment. Can you please point us to a place where we can escalate issues that cause problems in the bigger context?

I still cannot understand why the dev team would continuously deprioritize the issue with the most heat by far for such a long time.

[Ivan (copilot-language)]

I do not have a problem with the snap dev team deciding that this issue has no priority for them. That is absolutely fine. It an individual project, it's their project, nobody tells anyone else what to do with their time. To think that they owe us to fix it would be disrespectful imo.

But I do have a problem with Ubuntu promoting snaps then. I've been promoting and supporting the Ubuntu distribution for years, and creating tools that are compatible with it.

When a core tool changes, that's when it becomes *my* time. And the last few years have been particularly annoying.

I'm happy with this issue remaining unresolved forever, so long as Ubuntu stops installing snaps by default, and systematically promoting them.

[Douby (jan-doubravsky)]

Hello,

I have to comment here too. Pawel, it is not as you mention "important for SOME users". That some (in fact many) people are people using Ubuntu but not even know where complain about this issue. Sorry but I cant easily deploy Ubuntu for normal users (PCs for older people, or PCs for only browsing, accounting, etc.) because few days after are calling me and have questions about strange "snap" folder and how to get rid of it. I had even few cases that this annoying bug made them go back to Windows. They are really sensitive where everything is and why.

It is simple, do it right (or hidden by default) or dont put it in Ubuntu by default.

[eryksun (eryksun)]

I take it as given that Snap and various use cases were considered important enough to use a top-level directory in $HOME. That said, you can call me a pedantic, persnickety, nitpicker, but I dislike the default name "$HOME/snap" and that it's not configurable. The default name should follow the existing title-case convention, and it should be plural for a directory that contains multiple instances of the item class -- e.g. Downloads, Pictures, Videos, and even Music (a mass noun). I don't see "Snap" as a mass noun for Snap packages, so the default name should be "$HOME/Snaps".

[Thomas Perl (thp)]

Were there already good reasons why it can't follow XDG, if only via symlinks?
https://specifications.freedesktop.org/basedir-spec/basedir-spec-latest.html

Or if not, maybe there should be an updated XDG base dir specification that takes into account the requirements of Snap and Flatpak and other similar solutions?

Note that Desktop Linux isn't the only one having per-app directories, on macOS it's in "~/Library/Application Support" (and "Library" is hidden by default from Finder [file manager], but not in "ls") and on Windows it's "%HOME%/AppData" (again, hidden by default).

I got my system-installed Chromium package upgraded on 19.10, which pulled "snapd" back in (after I removed it a few days ago), so just "not using snap" isn't really an option for now (if on Ubuntu). Of course, Debian and Fedora provide a snap-less experience by default.

Given that third party vendors seem to prefer Flatpak, the Linux app updating experience gets more fragmented, from a simple "apt dist-upgrade" to an apt+flatpak+snap+whatever task.

At least Flatpak stores data in "$HOME/.var/app/" (from a visibility perspective), but that's still not XDG, so it's still bad.

Also, funny how the Chromium DEB->SNAP transition needed a folder migration (the blog post https://snapcraft.io/blog/chromium-in-ubuntu-deb-to-snap-transition says "an existing Chrimium user profile will be imported [provided there is enough disk space]), this could have been so much simpler (and not potentially break users' profiles or require more free disk space than strictly necessary).

Given that there won't be The Single Solution for Linux app packaging, it would be cool if user data could be shared between Snap/Flatpak/DEB installations of an app. Then it's really a matter of "your DEB is too old? grab the Snap or Flatpak!", and not "oh well that's not compatible, you have to move files around and hope for the best". Also allows for switching between DEB/Snap/Flatpak seemlessly without "vendor lock-in".

[dom (7-ubuntu-j)]

So basically, since my /home have very limited space, I install everything on another HD,
that just mean I can't use snap because it install automatically and without possibility to choose another location ?

Bummer, it looked promising enough :(

[Forest (foresto)]

I discovered this today when the ubuntu 19.10 upgrade replaced my chromium package with a snap, thereby creating this alien directory in my home dir. I believe my exact words were, "are you fucking kidding me?"

> at the end it's pure aesthetics.

Wrong. It obstructs tab completion in command lines and keyboard navigation in file managers, which is something that I do thousands of times per day. This makes it a rather significant attack on usability.

Even for people who don't use keyboards, the additional clutter adds cognitive load every time someone looks for a file or navigates to another directory. It also contributes to pushing other files off the edge of file manager windows, thereby either requiring the user to scroll to find things or to waste desktop space with larger file manager windows. You might think these to be minor effects, but that doesn't excuse it, and they add up quickly. Especially for the single most visible directory in the entire system.

> echo snap >> ~/.hidden

That doesn't work my terminal or my Thunar (file manager) windows.

> "me too" is not really bringing anything to the discussion.

I normally agree, but this is a special case. It would be difficult to overstate how foolish this design decision was. The flood of comments serve as a clear demonstration of that, and will (hopefully) ensure that the people responsible think more carefully before repeating their mistake in the future.

Consider also that each "me too" here represents not just the person who wrote it, but also multiple others who had the same reaction but didn't bother (or don't know how) to come here and write about it.

While we're at it, not that there wouldn't be so many "me too" comments if the snap folks hadn't left this problem unaddressed for nearly four years.

Four. Years.

Okay, so fixing it properly is difficult because of your rigid design. Okay, that happens; we all make mistakes. But maybe consider implementing a temporary fix early, so you don't leave people burdened with your mistake while you take four freaking years to fix it properly?

I am in disbelief.

Amusingly, I happen to be evaluating container-style packaging systems this week, with FlatPak and Snap on my short list because of their sandboxing features. The fact that this bug exists in the first place, along with the fact that it has been allowed to persist for nearly four years, has convinced me: I'm not building anything with snap.

[Forest (foresto)]

P.S.

Dear snap developers,

I do feel some empathy for you. You're trying to build something good, and share it with people. Taking heat while doing that mostly thankless job is tough. So, thank you for your efforts.

I chose not to censor my previous comment, though, because I have found that downplaying the significance of a problem is counterproductive in the long run. Things don't get fixed if the people who can fix them don't understand how problematic they are.

I can't wait another four years. Looks like I'm going to have to either find another way to use chromium on ubuntu, or else finally replace ubuntu.

[Leon Matthews (leon-matthews)]

@foresto You've done a good job of expressing my frustration with both the snap software, and the way it's being rolled out too.

Snap still 'smells' like experimental software to me - not a sold base for building an infrastructure upon.

This bug's namespace squatting in the home folder is the most egregious symptom, but let's not forget the horrors of running 'df' and 'fdisk -l' with snapd active! The pollution of home-folder backups is another that affects me (please let's not forget that not everybody has American-levels of band width and storage).

If we are sticking with snapd, can we please keep it entirely optional until it has matured a little more?

[Wolfgang (wolfgang-v)]

The dev team made it clear that for them it has no priority and from their point of view it is no bug and does not belong here. I actually really think that is a fair statement (although I really would love them to reconsider their point of view).

Does anybody know where the correct place is to discuss this further?

I have voiced my concerns directly to Ubuntu support last week as this might be the more appropriate channel for now. Although I thought they are listening here as well (see comment #11)

[Zygmunt Krynicki (zyga)]

Hey.

We _do_ consider this to be a bug but it doesn't have priority that high for us to drop other things. We have a draft plan on how to address this (~/snap having any name and being optionally hidden entirely) but we are still catching up with development from the previous cycle.

It is likely this will be picked up after 20.04 as a new cycle starts.

[Gustavo Niemeyer (niemeyer)]

> The dev team made it clear that for them it has no priority and from
their point of view it is no bug and does not belong here.

I actually stated something else way back above. We care, and we'll fix it. It's not as straightforward as it sounds, though, and indeed there were higher priorities. It's okay to disagree with our priorities, though.. it's easy to have an opinion on this, harder to make everyone happy all the time.

> I have voiced my concerns directly to Ubuntu support last week

We already have some good ideas for how we want that feature to shape up, and I'm hoping we can have something in the next cycle after 20.04 is fully baked. I don't do priorities alone, though, so that's not a promise. Feel free to reach out to me directly in the forum or online elsewhere if you're interested.

[chrm (ubuntu-one-3)]

This bug has 3684 "heat". The next worst bug has just 614 heat. Both are almost four years old. Both are tagged as "wishlist".

One and a half year ago it was (paraphrased) "this fix is easy when the epoch feature is done" and (quote) "For the record, the epoch feature is being actively worked on and it's not that far hopefully".

Now (quote) "It is likely this will be picked up after 20.04 as a new cycle starts". Not certain, just likely.

To me this sounds like you are just pushing technical debt in front of you ad infinitum.

[dorothea (dorothea2)]

This bug and the severe cluttering of the output of `fdisk -l` and `df` have made me decide to switch to Debian at my earliest convenience. The discomfort snap causes is simply too great and judging from this bug they may take years to fix, if they're even going to be fixed at all. I simply do not have the time to implement and maintain all kinds of workarounds.

I might check back in a year or so to see if things have improved.

[Janek Warchoł (janek-lilypond)]

Having an unwanted folder in my home directory, combined with how long it takes to fix an issue that so many people find annoying, makes me stop using snap. I'm going to rewrite my system setup scripts to use other methods of installing software (even if that means scraping websites to find download urls). It's a pity.

[David Megginson (david-megginson)]

I need to uninstall Gnome Calculator, because it keeps spamming my home folder with a "snap/" subdirectory. Fortunately, no other apps I use regularly have this bug. I'll look for a different calculator app.

[Tom Hanlon (tomhanlon)]

Agree with the comments here. /snap should not be polluting the home directory.

[Robin Lundgren (linkert)]

I agree with everything stated in comment #2 except that it's not 2017, *It's 2020, come on.*

Call me a superficial but I enjoy a nice and tidy home folder and this is the only reason why I go for the repos (currently on Void Linux) or in certain cases flatpaks over snaps. I would love to go for snaps. Just listened to episode 2 of season 13 of the Ubuntu Podcast where Popey had packaged up "ncspot" into a snap. I go to the ncspot github page and try installing it with cargo, the rust package thing and it fails with horrible error messages - no ncspot for me then.

Who do I pay and how much does the person in charge/responsible want to fix this? People all-over the planet will rejoice when this gets fixed.

[Michael Jensen (mjensen-t)]

I too have this problem. Please move the snap directory out of my home directory or make it .snap

[Frederik Abitz (fabby3)]

Hearing that this issue will only possibly, but not certainly be fixed after 20.04 is extremely disappointing to hear. I was planning on switching to Ubuntu for the upcoming LTS release, but after reading this I changed my plans.

I feel like this seemingly superficial, but practically important issue represents much of what is terrible about modern software. I like to call it narcissistic software. Software that is not only a useful tool, but behaves like it knows what's best for you. Sometimes to be different just because.

Whenever I see developers reacting to a rising complaint by telling the users THEY are wrong, especially when long-standing best practices are violated, I feel like the software is going to turn to shit in the long run.

Experimenting and breaking the rules is fine and can lead to great advancements, but many times it doesn't. This experiment is over. The results are in. Please just end it.

[ralphb (dev-endlos)]

Just how difficult can it be to rename the snap folder to ".snap"?

[ash (sersorrel)]

If you think it's so easy, why not try it yourself? snapd is free software, and I'm sure the maintainers would be grateful for a patch which fixes such a widely-shared issue.

[alex (kredikshaw150)]

It doesn't matter if it is difficult or easy. This issue has been going since 2017! it should be a priority.

[Thomas Wehmöller (mordragt)]

This is insane,
i am looking at this page like once in a month.... Since 2017, i really really want to use snaps. I have no words for this. I mean i get it, its more rewarding to implement new features over fixing old mistakes but just do the math. This are all the people that are so annoyed that they came here to express their disbelief, now think about all the users that are upset but dont find their way in here...

[Emil Bøgh Harder (kasteklar)]

Are there any official announcements of why they don't want to follow the XDG standards?

[Zygmunt Krynicki (zyga)]

Hey, a fellow snapd developer here. We do not use XDG locations for the following reasons:

1) They are configurable, per user, which would require per-user confinement that we currently do not support.

2) Ignoring that, the standard locations are not followed by *all* software uniformly so we need a location for things that do not fit XDG anyway. As an example, a snap of something like vim would use ~/.vim and ~/.vimrc outside of confinement. That would need mapping to _a_ path inside the confinement. We would have to have some form of ~/snap/vim/current/.vim anyway. Where would that go?

3) In addition to that, snapd manages application data and creates two distinct locations, the per-revision data set ~/snap/$SNAP_NAME/$SNAP_REVISION and ~/snap/$SNAP_NAME/common. This is essential to handle "snap revert" which rolls back both the application code and application data. There's no clear mapping of that to any of the XDG documented locations.

There may be additional reasons, I'd have to go back to my notes from the original design of this location many years ago. As a person who implements the lower-level parts of snapd, I can really say that doing anything about 1) is extremely hard and security sensitive.

[Oliver Grawert (ogra)]

To extend what zyga said above ...

A major amount of snaps are used on appliance, embedded, IoT and server devices (in fact snaps were used in these environments for two years already before they came to the desktop at all). On many of these systemd XDG doesnt even remotely play a role so it was originally not a big focus when snap development started in 2014...

[Wolfgang (wolfgang-v)]

My main issue is that the snap folder is visible in the file manager and on the command line by default. With .snap that would no longer be the case. Workarounds for all file managers / file dialogs / file listing commands are not always easy.

Is there any specific context in which it is important to have a snap folder that is visible by default? I just can't think of anything.

Even better (but just nice to have) would be any default location (even ~/snap) and the option to set a configuration file in e.g. /etc/snapd/ that allows to set a custom path that is read and interpreted during re-installation. This way regular users / users that don't bother don't have to do anything and all other users can make their own decision.

As you can see from the previous paragraph I am sadly not a very savvy developer. But I am very curious to know: Would the effort to migrate to another hardcoded location than the current one (e.g. ~/.snap) be more, less or similar to the effort with a user-configurable location?

[Zygmunt Krynicki (zyga)]

I understand the sentiment with ~/snap being a fixed location, shared by both yourself and other people who have commented here.

The cost of making ~/snap arbitrary is very high but we have some ideas that we are actively exploring as a part of the 20.10 cycle planning and I suspect there will be some exciting updates to share once the plans are more solid.

[Zygmunt Krynicki (zyga)]

To be clear, we've agreed to work on this in our cycle that runs for the next 6 months.

It's happening! :)

[GizmoChicken (gizmochicken)]

@zyga

GREAT NEWS! THANK YOU!!

[tellapu (tellapu)]

@zyga Wonderful! Thanks in advance for working on this!

[bitboy (zeus557)]

I didn't read all posts and i used snap yesterday for the first time.
I installed League of Legends which worked after a few tries, so great work. But my system has 2 hard drives, a fast (and small) SSD for system data and a classic one for large data. Now League of legends is about 10 Gb in my home dir which fills up the space and i'm not able to move the folder to my larger hard disk. This is a show stopper.

As i'm new to snap, this way it isn't possible to share a snap to a second user on the same machine. So if someone else wants to play lol too, it will cost another 10Gb i guess...

[Oliver Grawert (ogra)]

to move the content of the dir you might be able to:

stop all snap apps ...

mv ~/snap /whereever/your/bigger/disk/is/mounted
mkdir ~/snap
sudo mount --bind /whereever/your/bigger/disk/is/mounted/snap ~/snap

you might need to adjust permissions on the target disk, the snap dir must be fully read/write for the user using it ... and can indeed create a systemd mount unit to make this permanent ...

[bitboy (zeus557)]

@Oliver
thx that worked. Its required that your user is owner of the snap folder. A bit complicated to realise on an ntfs partition but possible.

[Harry Chen (chenhongqiao)]

@zyga
Thank you! That's awesome!

[Ty Poorman (flotts)]

It's been years. This is still annoying. May as well download my applications from websites like a Windows user if package management is going to be this dirty on Linux.

[Robin (tezaro)]

Egregious violation of the XDG specification, almost a thousand users actively complaining, years of stalling, and still Snap managers are explicitly saying that this bug is not a priority. You have to ask what they think IS important, or whether they care about their users at all. @zyga seems well-meaning, but still, the fact that this is difficult to fix is on Snap, no one else. It is the predictable result of a terrible design decision made by Snap early on. Time to quit stalling and call this bug a priority at last. Until it is fixed I have to purge Snap, no choice, like so many others here. What a silly situation.

[Gustavo Niemeyer (niemeyer)]

If not having a ~/snap in your home is more important than what the entire snap ecosystem provides, then removing it indeed sounds like the right choice.

With that said, we've been working on this issue and Zygmunt says so above quite clearly, because we care, and always did. But we can only care about so many things at a time, and there are literally millions of people using this system and many of them are making requests that we also care about.

Thanks for your contribution to the topic, Robin.

[GizmoChicken (gizmochicken)]

@niemeyer,

As someone commented on the potential urgency of this issue back in 2017 (see comments #14, #15, #19, etc.), I fully appreciate that this issue is complex and that your team is diligently working toward a solution. Also, I support snaps. Your work is appreciated! Ganbatte kudasai!!

Regards,
GizmoChicken

[Robin (tezaro)]

@niemeyer Your tone suggests that you do not understand why this seemingly small issue is so important to many people. It is NOT just esthetics, or rigid ideology. Others have mentioned issues with mounts and disk space. Or imagine having a script which follows the XDG spec, for backing up or syncing one's personal data or something similar. When Snap, which is now built into Ubuntu, comes out of nowhere and dumps large quantities of data, that will certainly require rewriting the script and may even have cost money if you were on a metered connection. This is wny, yes, I literally preferred purging Snap and resorting to jiggery-pokery by pinning a Debian APT repo just to get Chromium. So my comment was really in response to a remark by @stolowski that "our hands are full with other features, and of higher priority". Tell us at least, are there any other bugs that have as many users whining as this one? Perhaps the actual users should have a little more say in deciding priority.

[Avamander (avamander)]

The very least make it hidden. It's simply horrible in my neat home folder, there's really no arguing against that.

The resistance to fix it baffles me the most. Add a dot to the damn path and make the snapd package install script `mv` the folder if it exists before the upgrade. It's not that hard, you simply want to piss off more than a thousand users. That's not okay.

[Robin (tezaro)]

@avamander If you read carefully the discussion above you will see that the "resistance" has crumbled, this now seems to be a priority bug which will be fixed fairly soon. The Snap team made a bad design mistake which is harder to fix than it looks, see posts by @zyga for detail. Nobody "wants to piss off" anyone, that is silly. Most of us here are not paying customers, perhaps it would be good that we remember that.

[Avamander (avamander)]

> this now seems to be a priority bug which will be fixed fairly soon

Indicated by the status "Wishlist"?

> Nobody "wants to piss off" anyone, that is silly.

Oh it absolutely is. But two years, people have their limits when assuming good faith.

> Most of us here are not paying customers, perhaps it would be good that we remember that.

Do you think they'll get more paying customers basically ignoring a thousand + 1 people?

The community and it's voice matters - ignoring it will just cause people to not support Ubuntu. Support comes in many forms, money is just one of them. Support contracts aren't the only method either, people will take their donations elsewhere, they will influence the companies they work for not to choose Ubuntu. Some people will switch distributions, they will not recommend Ubuntu and might not even help people using Ubuntu. The effect is really not something to simply scoff at.

And I can't not mention how it absolutely is not in the spirit of FOSS to exclude people who are less well off. "If you don't pay, don't dare say anything" is such a privileged attitude.

[Zygmunt Krynicki (zyga)]

The real priority is on the upstream project. The Ubuntu package priority is irrelevant and I cannot change it.

[Gustavo Niemeyer (niemeyer)]

Folks, we said multiple times above that this is in the roadmap and there's on going work to get it addressed. We'll be posting more details about the actual change soon, and it's not just a rename.

> The community and it's voice matters - ignoring it will just cause people to not support Ubuntu.

At this point you are the one ignoring what others are saying.

[Robin (tezaro)]

>At this point you are the one ignoring what others are saying.

Come on @niemeyer, no point throwing fuel on the fire.

YOU guys screwed up bad with this. You have never really admitted that, just promised to fix it.

WE are whining about it annoyingly. We have made our point and should stop.

There. Everyone is wrong. End of discussion until there is new information.

[Gustavo Niemeyer (niemeyer)]

Right, I spent my time explaining the design and trationale that got us here, and in which direction we'll improve it. It seemed much more interesting for everyone.

> WE are whining about it annoyingly.

You are the one saying that. It is a hot topic for several reasons, but most people in this thread have been very reasonable.

[Seth (sysfu)]

@Gustavo, happy to hear that progress is being made after nearly three years of reports.

Do you have any estimate as to when the change will make it into the next Ubuntu LTS release?

[Gustavo Niemeyer (niemeyer)]

Hi Seth,

From recent conversations with the team, the approach has been discussed and we have an agreement on it, we should now see a design document made public in the next few weeks (september still, hopefully), which means an implementation available in the next few months. So we'll see it as part of the snapd release that will be in 21.04. We need to get it into one of the testing channels well before that, as this is a critical path that needs proper testing before being in a release.

[Corrado Topi (kermesse)]

I add my voice to the choir. We have two directories that can be used for all configuration and locally needed files, .config and .local.

[Zygmunt Krynicki (zyga)]

Those are not fixed locations. You'd have to cope with responding to the settings (that may differ per process) that govern their location. In addition the ~/snap directory is very explicitly, and non-trivially baked into apparmor profiles that are currently global to the system. This setting can vary per user. Lastly .config and .local and .cache are just top-level directories with absolutely no structure inside. Where do you put the per-snap $HOME? Is there a connection between a random dot-file like .vim or .vimrc that the snap writes to, relative to $HOME to .local or .config?

All nice solutions have the fatal flaw of being entirely unrealistic in practice.

[Avamander (avamander)]

> In addition the ~/snap directory is very explicitly, and non-trivially baked into apparmor profiles that are currently global to the system.

And whose fault is that? Should've thought about it sooner.

> Lastly .config and .local and .cache are just top-level directories with absolutely no structure inside.

And whose fault is that? You're absolutely free to create the structure you want, you've already mangled it, what does it matter now.

[Gustavo Niemeyer (niemeyer)]

Zygmunt, let's stick to the design and the spec only. Speculation or subjective remarks do not help the conversation.

Avamander, your personal notion of fault attribution won't help you or anyone else.

There's a lot of people here. Let's please preserve this thread relevant and respectful.

[Jamie Strandboge (jdstrand)]

> In addition the ~/snap directory is very explicitly, and non-trivially baked into apparmor profiles that are currently global to the system. This setting can vary per user.

We have mechanisms in AppArmor to help with alternate locations for things (there is the home tunable and we could add new ones for 'snap' or anything we want). This would not be difficult to implement policy-wise.

As mentioned several times in this thread, the issues are bigger than that. To Gustavo's point, there is a design and a specification for addressing this bug in a nice way, and it is on the current roadmap. This bug will be fixed.

[GizmoChicken (gizmochicken)]

I was an early and vocal critic of the "$HOME/snap" directory who:

(a) complained about this issue in numerous comments, including comment #14 (posted 2017-04-16), comment #15 (posted 2017-05-20), comment #19 (posted 2017-07-12), and comment #32 (posted 2017-10-22);

(b) reverted the status of this issue back to "Confirmed" (after another moved it to “Opinion”) on 2018-02-25; and

(c) edited the summary to succinctly read "Please move the "$HOME/snap" directory to a less obtrusive location" on 2018-02-25.

As an early and vocal critic of the "$HOME/snap" directory, I humbly and respectfully ask the following favor of those who continue to post here complaining about this bug:

STOP IT!

The devs have heard us, they are diligently working to solve this issue, and they will provide a solution as soon as practicable.

Thank you for your understanding. :)

[David Norris (dvnrrs)]

You say "as soon as practicable" but this bug is over 4 YEARS old now. I think the frustration from the users is completely understandable and justified. It's by far the hottest issue on the list but the developers continue to waffle. Not that I think one more post is going to change anything, except to increase the visibility of the fact that this is such a ridiculously mismanaged and misprioritized project. I see that as a good thing.

If the periodic emails annoy you, you can always un-watch the issue.

[Gustavo Niemeyer (niemeyer)]

> a ridiculously mismanaged and misprioritized project

So you create an account just to come here say that? Indeed we have different a notion of priorities and time allocation, David.

[Avamander (avamander)]

So are we now shaming people because that they are personally affected by a bug for years, that decided to participate in the community?

I suspect the reaction would be a lot milder without all this thinly-veiled condescension constantly thrown at people here. I'm personally appalled.

[Gustavo Niemeyer (niemeyer)]

This is a place for respectful collaboration about the project and the issue at hand. People in the community are most welcome to participate and help, and many have done exactly that.

Insults and blaming are not welcome here or anywhere else in this community, though, no matter how much you care about it. If we're unable to talk about the actual issue here due to this kind of behavior, we'll lock it down and move the conversation elsewhere.

[David Norris (dvnrrs)]

I already had an account, it's totally fine (see comments #184 and #192).

I'm not individuality insulting anyone and I'm also not trying to be rude. But come on, 4 years? If the developers are going to drag their feet that long - an outright eternity in software development terms - on such a high profile issue, even after such a strong community response, then in my professional opinion they should not be at all surprised when people find the project mismanaged.

Purging snapd is literally the first thing I do after any new Ubuntu installs. I consider it bloatware and just shy of malware. I wish I didn't have to.

[Gustavo Niemeyer (niemeyer)]

The way we select priorities for the project every single cycle for years is having several stakeholders (that's more than a dozen people, covering community, customers, development groups, etc) with several different perspectives in a room after having followed a process of funneling requirements from these same groups over several weeks. We then have a long discussion to agree on what are the most important priorities for the project for the coming cycle, and then a fantastic development team works on these features for the next several months, often doing minor adjustments to the roadmap as the cycle progresses and we have new factors coming in.

I realize that sitting here in a bug for 4 years waiting for your pet peeve to be fixed may be unsettling and frustrating, but hopefully the interactions from the team in the history above are good data to show that we've been around all along and did intend to improve things eventually. Not in your preferred timeline, unfortunately, but we have many more issues and voices to pay attention to.

That's why you see https://snapcraft.io/store and the snap project and community being what they are today. Because we do care, and we do follow a process that is not just hand-picking issues arbitrarily.

I'm sorry that you prefer to remove the application and vote yourself out of this community, but this is a freedom we also appreciate around here. We're glad you can make yourself comfortable with other tools. We'll stay here, improving things meanwhile.

[Avamander (avamander)]

> Not in your preferred timeline, unfortunately, but we have many more issues and voices to pay attention to.

How do you have "many more" voices to pay attention to? 1018 people have marked this issue as it affects them, if anything, you have *many fewer* voices to listen to elsewhere.

> waiting for your pet peeve to be fixed may be unsettling and frustrating
> We'll stay here, improving things meanwhile.

This is exactly the thin-veiled condescension I mentioned earlier.

"I'm sorry you chose to feel insulted or blamed by earlier comments by dvnrrs."

[Gustavo Niemeyer (niemeyer)]

> How do you have "many more" voices to pay attention to? 1018 people have marked

We have millions of users, Avamander.

> "I'm sorry you chose to feel insulted

Your words.

Now I'll stop here and hope that we can go back to being productive on this issue. Failing that, we'll lock this thread up so we can all focus on the project development.

[Nabil Anam (nabil-anam)]

This needs to go

[Kevin Dong (kevin-dong-nai-jia)]

For whom does not care about multi users and backward compatibility, this is actually quite straightforward to change the snap directory from '$HOME/snap' to '$HOME/.snap'. Changing the hard-coded path and the AppArmor rule is fairly enough for release 2.46:

diff --git a/dirs/dirs.go b/dirs/dirs.go
index 2986ef371a..ea37ad195e 100644
--- a/dirs/dirs.go
+++ b/dirs/dirs.go
@@ -136 +136 @@ const (
- UserHomeSnapDir = "snap"
+ UserHomeSnapDir = ".snap"
diff --git a/cmd/snap-confine/snap-confine.apparmor.in b/cmd/snap-confine/snap-confine.apparmor.in
index 8b53423ca0..cde82139b5 100644
--- a/cmd/snap-confine/snap-confine.apparmor.in
+++ b/cmd/snap-confine/snap-confine.apparmor.in
@@ -346 +346 @@
- @{HOME}/snap/{,*/,*/*/} rw,
+ @{HOME}/.snap/{,*/,*/*/} rw,

[Julián Tovar (polirecyliente)]

I was doing a cleanup of my $HOME directory, and sadly I found this "snap" dir, this made me follow through and find this open issue... open for MORE than FOUR years already... is this fixable? Because if it's fixable and this much time has happened I can't help but to feel contempt for the snap project... but if it's IMPOSSIBLE to fix then I feel pity for snap... but anyways, my views on this have no relevance, I'm just a single user, and I only have three applications installed with snap: Audacity, VLC, and Chromium. I was able to build Audacity from source, and I'm sure that there is a way to use VLC and Chromium without Snap, there has to be a way, so even if I purge snap, I'm just a random person of the world, it's not going to change anything, just one more of the many affected by this design that shouldn't have even existed in the first place. So, why even write? So the people at the Snap project can see that they are getting uninstalled BECAUSE OF THIS ISSUE.

[GizmoChicken (gizmochicken)]

@polirecyliente,

Please allow me to reiterate what I wrote in post #265 of this thread:

>I was an early and vocal critic of the "$HOME/snap" directory who:
>
>(a) complained about this issue in numerous comments, including comment #14 (posted 2017-04-16), >comment #15 (posted 2017-05-20), comment #19 (posted 2017-07-12), and comment #32 (posted >2017-10-22);
>
>(b) reverted the status of this issue back to "Confirmed" (after another moved it to “Opinion”) >on 2018-02-25; and
>
>(c) edited the summary to succinctly read "Please move the "$HOME/snap" directory to a less >obtrusive location" on 2018-02-25.
>
>As an early and vocal critic of the "$HOME/snap" directory, I humbly and respectfully ask the >following favor of those who continue to post here complaining about this bug:
>
>STOP IT!
>
>The devs have heard us, they are diligently working to solve this issue, and they will provide a >solution as soon as practicable.
>
>Thank you for your understanding. :)
>

tl;dl:

STOP IT!

The devs have heard us, they are diligently working to solve this issue, and they will provide a solution as soon as practicable.

Thank you for your understanding. :)

[iBART (mogio)]

It is insane... it affects me too!

[Mr Aaron J Michaux (amichaux)]

I came up with a convenient solution. I added the following to my crontab:

* * * * * rm -rf /home/amichaux/snap

Works like a charm.

[Facundo Quiroga (facundoq)]

I really appreciate the effort put into snapd. However, as a fellow software developer, I honestly fail to understand how an issue that's been going on for 4 years and has the most heat of all issues (https://bugs.launchpad.net/ubuntu/+source/snapd/+bugs?orderby=-heat&start=0), that depends on **being able to configure a base folder for snaps** requires a design document after 4 years of discussion. Specially when as mentioned before, the linux ecosystem already has defaults for this (ie, .local/, etc), or maybe a SNAPS_HOME env var?. I'm really curious as to how the current design precludes a simple fix. Any suggested link to read about this?

[ash (sersorrel)]

I would suggest you read through the past comments on this issue, and the design document you mention. For example, "put things in the XDG directories (~/.local, ~/.cache, ~/.config)" has been suggested many times; it's explained earlier in the comments here (e.g. comment #30) why that wouldn't work, and the same applies to an environment variable like $SNAPS_HOME.

[Some Dude (dudes5744)]

I found this page helpful,
https://www.kevin-custer.com/blog/disabling-snaps-in-ubuntu-20-04/

[praesepe (praesepe)]

20.10
/home/user/snap still there...
I have a bad impression that he will never leave

[Wolfgang (wolfgang-v)]

My hopes are still up - see comment #259 for some more information about the process: https://bugs.launchpad.net/ubuntu/+source/snapd/+bug/1575053/comments/259

I really hope 21.04 still is reachable. Not sure where to find the public design document though (or if it even exists yet).

[Tobi Schäfer (interface)]

:thumbs_down:

[Thomas Wehmöller (mordragt)]

From a high level view it seems like the project is far from being usable in mission critical systems if there are so many other problems that are prioritized over this community outrage. But maybe i am wrong and user feedback is just not valued here.

[Jean (jean-miguel)]

We just updated all of our Ubuntu installations to 20.04 and first everything seems very smooth. But after installing chromium-browser the annoyances began. After slow program starts we realized it's no real deb package anymore and it silently installs a snap! Then users realized the intrusive /home/user/snap folder and asked to move it out of their home directory.

My research took me to this snapd bug and I can't believe this is debated for MORE THAN FOUR YEARS! And there is still no config option available. Holy shit! How is that possible?

This snap thing is not ready for production! All snap applications need more than 10 seconds to start on fast SDD systems and bring this intrusive snap folder in the home directory. I can't belive that.

Seems Ubuntu is going the Windows 10 way and annoying the user more and more and ships shiny objects which try so solve problems that doesn't even exist. Now we have to uninstall all this snap stuff again and search for the corresponding deb packages Ubuntu has ditched.

We really hope Ubuntu will notice they have gone astray and the next LTS version will rely on 100% deb repos again. Otherwise lot's of people will make a switch to other snap-free distros.

[Kyan Jiao (kyanj)]

This is my first time using snap, and i realized there's a 'snap' folder in my $HOME. Google redirected me here. It's really a surprise that this is still not fixed in 4.5 years.

We don't care those internal stuff. Please just get rid of this folder, no more excuses. There are millions of linux tools, and I really don't understand why snap is special and insisting on creating a visible folder in $HOME.

[Wolfgang (wolfgang-v)]

@jean-miguel and anyone else affected: Please report your feedback to Ubuntu customer support too, so that they can draw their own conclusion on how their product decisions affect their user base.

[GizmoChicken (gizmochicken)]

Wolfgang (wolfgang-v) wrote:

>@jean-miguel and anyone else affected: Please report your feedback to Ubuntu customer support too, so that they can draw their own conclusion on how their product decisions affect their user base.

Wolfgang, you forgot to suggest that all dissatisfied users should DEMAND a FULL REFUND of the licensing fees charged by Canonical to use their FREE software. :)

[Wolfgang (wolfgang-v)]

GizmoChicken, I apologize for my post. Wanted to delete it but cannot figure out how.

Was just so frustrated in the moment about the non-communication about progress and that Canonical decided to push snap in the current state, even though they participated from the beginning in this thread and are fully aware that they are putting a visible directory right in the user home directory that cannot be moved/renamed.

I try to be hopeful, but sometimes it is getting so difficult. Was so hyped about comment #259. Maybe I am just not familiar enough with the process. Do you know where this design document was published? Just anxious that there is no progress and it was just an empty announcement.

[GizmoChicken (gizmochicken)]

@Wolfgang: No worries. And as an early and vocal critic of the "$HOME/snap" directory (see post #14, for example), I share your frustration. But I've come to realize that devs truly want to, and are working to, resolve the issue. We (the users of this FREE software) just need to be patient. And for those of us who can't be patient, removing snapd remains an option. As for me, I'll keep snapd for now, and continue to wait patiently for an eventual fix. :)

[Chris Vanden Berghe (chrisvdb)]

Was wondering if this is still scheduled for 21.04 as suggested in the below comment by @niemeyer...

> From recent conversations with the team, the approach has been discussed and we have
> an agreement on it, we should now see a design document made public in the next few
> weeks (september still, hopefully), which means an implementation available in the
> next few months. So we'll see it as part of the snapd release that will be in 21.04.

[Sebastian Makowiecki (soocki)]

Hello kind pple, pretty please move this dir from the central home location, it does not belong there! Thank you kindly.

[Sebastian Makowiecki (soocki)]

Ah my apologies was it fixed? Am I still running an old version? Thank you thank you thank you!

[Sergei Veselovskii (whitebearspirit)]

Hey guys what about the fix?
Placing a directory that was meant to be hidden to user's home dir is uncool.

[Roberto Lobo (rhlobo+launchpad)]

@Gustavo and dev team

In #259 it was said that an approach has been discussed and agreement uppon. I understand that on 2021-03-29 a fix was confirmed, although I could not find anything on the matter (including the design document).

I am running snap/snapd 2-50 (full system, fresh install) and a snap dir was created here. I am not demanding things be my way, but I am putting huge effort to build my system from ground up, eading/learning/configuring everything as much as possible, and have no clue how this matter evolved (far more clueless than an blind person on a wild west shooting).

This thread has been quite inactive lately and I would be gratefull if someone could clarify if something was changed/fixed (then I know something is missconfigured on my side).

I undestand that better xdg portal integration was released, bit as I am running arch + xmonad I dont have that setup (has lots of deps including gnome-desktop). Does that has something to do with that?

Thanks in advance

[Nagy Gergely (nagygeri11)]

I humbly want to express my disbelief in that such a seemingly simple problem: hiding Snap's own directory from the $HOME, which seems as easy as renaming $HOME/snapd to $HOME/.snapd, has been going on for 5 years, with a number of proposals and promises arising (as early as in [#18](https://bugs.launchpad.net/snapd/+bug/1575053/comments/18) in 2017) and failing to deliver. Especially as this is the top bug report.

In 2017 it was pointed out that a fix should happen ASAP before Snap rolls out, and I agree - I guess that shot was already missed by long.

I fail to understand why Snap's data folder was visibly placed in $HOME in the first place, when it was a widely accepted consensus that data folders of specific apps must be hidden somehow. This really should be fixed promptly, it's ugly.

In any case, to me it seems to highlight some fundamental design problem that we have a hard-coded string in the codebase, that seems to be such a huge trouble to modify by even as little as adding a "." to it.

[Ivan (ivanperez-nfm)]

I would not have that big a problem if Ubuntu had not made it the preferred way of installing and packaging apps now.

It highlights more fundamental issues with the design of snap, with the management, and with the way that it was included and promoted. And this is just one issue that is relatively simple. But if it had been a serious issue that affected packages, would it also have taken more than 5 years to address?

Is there a way to escalate this to the team at Canonical that made the decision to bring snap in in the first place?

[Nathan Hunt (nathanhunt)]

I finally resorted to the uninstall snap workaround. Annoying users and being intrusive is a solid way to ensure the success of a package you're responsible for.

[Karl Ljungkvist (k-ljungkvist)]

Seeing how this has been treated for 4.5 years makes this seem like a pretty dysfunctional project. Please have mercy on your poor users and fix this.

[Robin (tezaro)]

To Snap and Ubuntu developers, here is a concrete example of why this is important and so many people are annoyed.

Imagine a user likes to back up their home directory. (Imagine that! Crazy stuff!)

The user will likely exclude hidden files from the backup, so as to avoid filling their storage with useless cruft, and maybe to avoid hitting storage or bandwidth limits (which can result in unexpected bills).

By squatting the user's home directory, uninvited, Snap screws everything up. The user will need to hard-code an exception into the backup script. For one package. All the other packages respect the XDG rules. All of them except Snap.

To Ubuntu developers in particular: by switching APT packages to Snap (Chromium for instance) and thereby causing an `apt install` to pull in Snap unrequested, you are breaking people's home directories, their scripts, their backup solutions, and the rules.

[Danny Trunk (dtrunk90-deactivatedaccount)]

After 5 years there's still no fix. This is so annoying. I'm now getting rid of all snap packages and installing deb variants instead. Finally I'll purge snap and if these weird decisions keep on going I'll also move to another distro. Common Canonical. Seriously?

[Alex Murray (alexmurray)]

This is actively being worked on - for those interested you can follow the progress in https://github.com/snapcore/snapd/pull/10836

[Dimitri Papadopoulos (dimitri-papadopoulos)]

Note that .snap is also the default location of snapshots of the Ceph file system (https://github.com/ceph/ceph). It's a hidden (not visible during a directory listing) directory available in each directory of a mounted Ceph file system. See:
https://docs.ceph.com/en/latest/dev/cephfs-snapshots/

So if $HOME lives on a Ceph file system, ~/.snap (associated to snap) will clash with ~/.snap (associated to Ceph). A different location is needed, such as ~/.congif/snap/config for example.

[Avamander (avamander)]

@dimitri-papadopoulos

If there's a high likelihood that ceph will be used on a desktop distribution then its choice of snapshot directory has been incorrect in two ways. The way forward would be to not ignore conventions designed to avoid such issues :)

[Luke (lukeweller-deactivatedaccount)]

Is anyone from Canonical actually working on this bug? And why tf is this still considered a "Wishlist" item after 1200 user reports and hundreds of comments?

[Maciej Borzecki (maciek-borzecki)]

@lukeweller 3 commens up there's: https://bugs.launchpad.net/ubuntu/+source/snapd/+bug/1575053/comments/308 there's also a forum topic with more details: https://forum.snapcraft.io/t/experimental-flag-for-hiding-snap/28509

[Luke (lukeweller-deactivatedaccount)]

@Maciej Borzecki So that's it? There's an experimental setting I can use to manually move my ~snap folder. No documentation to go with it? No plans to actually implement this feature for anyone who isn't extremely tech literate?

That solution is less helpful than the ~/.hidden workaround that the userbase figured out years ago

[Maciej Borzecki (maciek-borzecki)]

@lukeweller you probably guessed this is not part of any release yet. Documentation will be there in due time. In the meantime you're welcome to contribute to the discussion in the forum or grab snapd from edge and try it out yourself.

[Luke (lukeweller-deactivatedaccount)]

@Maciej Borzecki I'll believe that when I see it.

This thread is a five-year history of users requesting a fix and the dev team responding that the users are stupid and it's not really a big problem.

Why should we believe you that this will ever be fixed, let alone documented?

[Wolfgang (wolfgang-v)]

I was so excited to see the link with more info on what the migration will look like: https://forum.snapcraft.io/t/experimental-flag-for-hiding-snap/28509/21

...only to find out that the end goal is to introduce a new ~/Snap directory (that - if I understand correctly - again cannot be changed by the user).

Prepare for another 5 years of pleading with the devs about the same issue again. Even before the old issue even was resolved.

[Ivan (ivanperez-nfm)]

I would not care anymore were it not for the fact that snap is becoming the default. We will have a less and less usable system if we just remove snap.

Can we not just request to the Ubuntu team that snap be removed from the default installation, and that no package should be made available only via Snap? (for example, currently, chromium is only available via snap).

[Ivan (ivanperez-nfm)]

Given that this is affecting so many people: I've opened a request against Ubuntu-meta so that Snap stops being recommended by default and we make sure no packages provide snap-based installation only:

https://bugs.launchpad.net/ubuntu/+source/ubuntu-meta/+bug/1965535

Feel free to comment there.

[Forest (foresto)]

Thank you, Ivan. I have add my "affects me" status and a comment there.

[Alex Cabal (acabal)]

Before 22.04 I was able to just uninstall snapd to remove ~/snap, and that was fine.

But now that Firefox is being delivered as only a Snap in 22.04, I'm essentially being strong-armed into using snaps, because Firefox is probably the most critical piece of software on my system and I cannot work without it.

Given this new situation, the ~/snap folder has gone from an annoyance that can be fixed by uninstalling snapd, to an intolerable situation that I will literally switch distros over. It makes me irrationally angry to have a piece of low-level systems software that I rarely want to interact with park its junk right in the middle of $HOME, the place where I organize my personal documents. Why not make ~/dconf or ~/pam while we're at it?

Please don't make me leave Ubuntu in 22.04 - just move the damn folder to ~/.snap or even better ~/.local/snap already.

A forums thread was mentioned earlier in this bug report where the snap maintainers change ~/snap to ~/.snap ... BUT THEN THEY GO ON TO CREATE ~/Snap! Come on!!

[Forest (foresto)]

The effectively forced use of Snap is what finally drove me to abandon Ubuntu. This issue played a part in that.

To be clear, I am in favor of app isolation on desktop linux, and I find container-based packaging useful in certain situations. However, the Snap project has demonstrated over and over again that the people driving it fail to grasp important issues like user agency and open systems. Like Alex, I find the result intolerable. Being rid of it was worth the temporary pain of switching distros.

So long, Ubuntu, and thanks for all the fish.

[yannek (yannek-deactivatedaccount)]

I can only echo acabal, foresto and a lot of the above comments. The technical merit of snap is not the point. But cluttering the homedir as a default _and_ offering no way around is not acceptable from any application. Hidden folders do exist for a reason, /var exists for a reason.

In the end, this gave the impulse to finally move over to Debian. After more than fifteen years of Ubuntu. I fear that you're destroying a lot of well earned goodwill. :-(

Please fix this for the sake of Ubuntu.

[Eric Mazoob (zoob)]

I just upgraded to 22.04, and was unpleasantly surprised to see ~/snap as a new directory in HOME. If there is no solution for this issue I will be switching back to Fedora.

[Kevin Dong (kevin-dong-nai-jia)]

For someone who is still struggling with this,
https://forum.snapcraft.io/t/experimental-flag-for-hiding-snap/28509
may prevent snap from storing data in ~/snap folder.

However, it seems that
sudo snap set system experimental.hidden-snap-folder=true
works and puts data in ~/.snap/data, but snap still creates an empty ~/snap on app startups.

Fortunately, we could always leverage crond
* * * * * rmdir ~/snap
to remove the directory when it is empty though. ;-)

[Zingam (registrirayme)]

Just add an UI option to hide this folder from the system.

[Coeur Noir (coeur-noir)]

echo snap >> ~/.hidden

Might be a default configuration for all new users if included in /etc/skel ?

[Stephan Matthiesen (info-stephan-matthiesen)]

Now that we are forced to use snap for Firefox, this should really be fixed.

I was also very unpleasantly surprised to have snap appear in my home directory. The workaround with .hidden is not real a solution.

I had avoided using snap in previous Ubuntu versions but with the Firefox change this is getting harder.

[Little Girl (littlergirl)]

I'd like to heartily agree with this bug six years after it was first filed (currently in Kubuntuu 22.04 LTS). This is a visible directory in the Home directory and it's there by default along with all the other default directories. Since it doesn't follow the naming convention of having an upper-case first letter, it not only looks silly, but also interferes with case-sensitive sorting done by some programs. I would be fine with it either being given an upper-case first letter or being made hidden in the event that we're not intended to manually interact with it. Please fix this.

[Nathaniel Wilson (dubrict)]

What truly bothers me about this is the following:

1. Cluttering the home directory is a disorganized practice.
2. The purpose of package management systems like snap is to organize software.
3. Therefore snap violates its own purpose by creating disorganization while it organizes.
   The snap system is fundamentally disorganized by design.

I would compare it to a food pantry that throws away food... a police officer who drives recklessly... a dishwasher that cleans the dishes but throws food particles onto the floor... I could go on and on with ridiculous examples of things that do the opposite of what they are supposed to do.

[Tux to BSD (tux2bsd)]

It belongs under ~/.config or ~/.local

Reported in 2016! This is incompetence beyond comprehension, you're giving the Democrats some solid competition... even Sleepy Joe's quicker than you lot!

[liuxin (liuxinux)]

I have never seen such arrogant software and developers. This is a foolish act. I will uninstall snap until this problem is solved. Or, I think I can try to abandon Ubuntu. Debian or Fedora may be a better choice.

[Patrick K. Etienne (sulaweyo)]

It's been at least a few years since I've last checked on this issue. When initially exploring snap as a solution for application packaging, I discovered that the snap developers had decided to address a technical / security related issue by implementing a "hard coded" solution - one which, though maybe convenient for snap developers, goes against popular (an understatement) both formal and informal standards (mentioned in many previous comments). With this being the case, and since that original date a few years back, I have not developed apps in or utilized existing apps using snap and have instead used other solutions. Id est, my development and utilization behavior is as though snap does not exist. Snap will continue not to exist as an option (for my uses) until (at least) this issue has been adequately resolved.

As a side note, others have mentioned the "arrogance" involved in this decision. I've encountered plenty of what I would characterize as "questionable" decisions by development teams, however I have to say that this one is certainly "outstanding", not at all in a good way. I don't have the time or inclination to probe further into why hard coding a directory location is a feasible solution to a security issue, but fortunately snap has enough competition that I can effectively forget that snap exists for years at a time without either feeling like I'm missing anything or having the lack of it impact my productivity.

Not that alternatives to snap are by any means perfect, but thank goodness for the competition.

Cheers all =)

[Coeur Noir (coeur-noir)]

cd ~
echo snap >> ~/.hidden

Done, snap folder is hidden as any other folders and files related to user's setting, parameters and config's.

[Hadmut Danisch (hadmut)]

Seems to have no effect at all on ls command.

[Daniel Gleason (dnlglsn)]

I am amazed how long this bug has been open; it is one of the major reasons why I entirely purge snap from my system when I install Ubuntu.

I moved from Windows to Ubuntu for freedom of choice. The bug described here removes my freedom to organize my files how I want to. It is making me question whether I continue with Ubuntu in the future or move to a different Linux flavor.

[Harpreet Singh (devhs89)]

What is being done about this!? It's been 4 freaking years!!

[David Megginson (david-megginson)]

Why is this still cluttering my home directory? Please just move it inside .config

[Davide (davide-cester)]

A little user update...

I'm still with Ubuntu 20.04, I completely purged snapd and my Firefox is installed as .deb. Still, every now and then Firefox creates ~/snap/firefox, meaning that the thing is now becoming somehow hardcoded or at least impossible to completely get rid of.

I recently became less annoyed about this issue, I think I understand better what the real topic is. We're complaining about the usage of Linux $HOME but this is not the old Linux anymore, it's more Android or iOS. Nobody opens bug complaining about directory structure in Android, do you? Nobody cares how big the Android Apps are, or where exactly they are installed, as long as they can access the camera and upload to Instagram. Nobody complains about the output of df under Android. And IMHO Ubuntu has taken this path, and if you (and I) have the 'ls' output of $HOME as priority then switch to standard Linux.

I don't consider this a bug anymore, it's a design feature of the new way of distributing software, and I think it will never be fixed because Snap is not about having a nice $HOME folder nor respecting the UNIX folder conventions from 1970. The bug is in our expectations.

[Aljoscha Vollmerhaus (avollmerhaus)]

I can understand your reasoning, I surely don't care about folder layout on my Android device.
But I am also fully aware that my Android device is essentially operated by Google.
They do whatever they want with the device, and I'm merely a consumer that gets to use the browser and a few other apps.
My computer is different. It's MY device. I get to make the rules. This is what free software was all about in the first place.
Since Firefox got converted to a snap, it takes ages to load on my girlfriends old laptop.
Sometimes, it doesn't start at all and just gives a black window so you have to close and re-open.
And in my dayjob, I had big problems with the chromium snap and Gnome Window management when trying to use the kiosk mode to make a web-app.

I would like to get rid of snaps, but I can't since Canonical has decided for me.
And while this bug is about a stupid folder that won't go away, for many of us it's about Canonical not having our best interests at heart any more.
That's why I'm leaving the Canonical ecosystem. And I'm taking my employer's infrastructure with me.

[Gustavo Niemeyer (niemeyer)]

There's still on going work, but you're certainly right about moving on. As much as I feel bad for having this buh open for so long, we're a small team that haven't been sitting on our hands and don't welcome that kind of disrespect here, no matter how much you'd prefer for us to have done something else with the time we have.

[Hadmut Danisch (hadmut)]

Well, maybe people are somewhat upset because snap is not offered as an option, but enforced by having important tools like Firefox and Chrome-Browser as a snap only.

So while respecting your work and the limited time and small team on one hand, it is on the other hand lack of respect for the work and limited time of all those people out there using ubuntu, by enforcing the rather raw product of a small team with limited time.

I'm not going to jump into this discussion about the name of ~/snap, although I admit, I find it disturbing too. I also had a long list of problems and wasted time to debug problems with snap due to insufficient documentation and questionable design decisions.

I remember pretty well the time when I had the problem that snapd caused me costs and problems, because it self-actingly downloaded mega- and gigabytes while refreshing snaps although I was an a really thin and metered expensive Internet connection. The ignorant answer from the team was, that they do want it that way, and don't care about other peoples situation. Or just trying to figure out what the hell snap is doing at runtime, because things were not working, but no documentation available about what is going on. Cost me a lot of time.

So I do consider it as inappropriate, if you demand respect for your team, while on the same time your design decisions do not pay any respect to Ubuntu users, and do not give them a choice whether to use snap or not. If your work is till going on and your time is limited, then maybe it was just too early to enforce the use of snapd.

Respect is not a one-way street. What goes around comes around.

[Gustavo Niemeyer (niemeyer)]

I said nothing about respecting my work. We have a base level code of conduct, and people in this community are expected to respect each other, whether there's agreement or not. Failing that, nothing else makes sense and indeed you're better off moving out so other people can talk and help each other.

[Little Girl (littlergirl)]

I have to agree with Hadmut that if the team is so small and busy with other things that it hasn't been able to address a high-importance bug that's causing a disturbance for users in nearly 7 years, then it seems that the decision to make it a default was premature. Is there any way the team can back-pedal on that decision until the team is more prepared?

[bornagainpenguin (bornagainpenguin)]

Six years later and this is still an issue.

Can we please get an option to remove Snaps on install, or even prior to install the way a user can select to use different filesystems when installing? It makes no sense for such half-baked solutions to be pushed as hard as this seems to be. It's been what? Six? Seven years since post #11? When Mark Shuttleworth cannot get something fixed in Mark Shuttleworth's distro you know there is a problem...

[Randall Leeds (randall-leeds)]

sudo snap set system experimental.hidden-snap-folder=true

I had to move some folders from ~/snap to ~/.snap/data manually, rather than wait for a new version of those snaps in order for a refresh to migrate them. But after uninstall / reinstall of the ones I moved manually, I now no longer have a ~/snap directory.

I don't think there's any bug here. This is working as intended and there's a working alternative for folks who don't want ~/snap.

[ariel (garcia)]

Another "me too" after I installed snap and then suddenly "WTF is there"!!? ;-P
Amazed to see that it took 6 years to have a configuration option allowing to put it where it should have been in the very first place. Yes, Apparmor profiles could be a reason why this is not easily configurable, but why not use ~/.snap or even better, ~/.config/snap from day 0?

Anyways, not only complaining: a big thanks to the developers for the nice tool! :-D

[PersianGolf (persiangolf81)]

Love snaps but putting a "Snap" folder, hidden or not, inside /home/$USER is really annoying. Please follow XDG and put the folder inside .local or .cache or other subdirs that already exist in home folder.

Thanks

[Hadmut Danisch (hadmut)]

I do agree with #350.

[Blotch Dog (blotch-f)]

Is there any chance that 'system experimental.hidden-snap-folder=true' will become the default for 24.04 LTS?

[warpi (warpi)]

Please move or atleast .hide the folder.

[Roland Hutchinson (orlandus)]

Agree wholeheartedly with #89 and #350 (except for the part in #350 about loving snaps--they are a major reason why people are leaving Ubuntu, of course; YMMV).

It is annoying that snaps have been designed broken in this way; it is even more annoying that this bug has now remained unfixed for almost eight years.

[Diego Bauleo (dgbauleo)]

I've been a user of Ubuntu ever since Warty Warthog, when Canonical used to ship the installation CD worldwide for free. Now I'm officially moving to Fedora due Canonical trying to shove Snap down our throats.
Congratulations on destroying what could potentially be the Linux Distro To Rule Them All by trying to solve a problem that never really existed with a terrible tool.

[Joseph Erdosy (stochasticsanity)]

Adding my voice to this. I will continue to run `sudo apt autoremove --purge snapd` as the first command on every fresh installation of Ubuntu until they no longer live in ~/snap. ~/.snap is a perfectly acceptable alternative, ~/.local/snap is even better.

I will not use snaps - and if that breaks things, that's fine. As far as I am concerned, those breakages are a bug. Any features lacking after the removal simply make Ubuntu inferior to other projects with less fragmented package systems - and if it is inferior to other fully FOSS products, then I will move to Fedora or other, less fragmented and more feature ecosystems - as is my duty as a user.

Personally, just like Unity, I'd rather Canonical ditch snaps all together if this is the quality of software we can expect from them. Don't do what you're bad at - you suck at user experience.

[Tony Cooper (aecooper)]

The only really sensible use case for Snaps, if any, is packaging software that will never make it into an official repository, like some 3rd party software, e.g. MS-Office suite, or Photoshop. Servers use docker or podman to deploy services. But what ever you do, please sort out the mess with snap. Allow if not user control as to where things go, then at a system wide level, or failing that just at least pick sensible defaults for your hardwired locations:

~/snap -> ~/.local/snap
/snap -> /usr/snap
etc

Hide snap specific loopback mounts in df.

Snap is currently a mess and just sorting this one ticket would probably stop quite a bit of the pushback you are getting on Snap. Obviously there are many other things wrong with snap as stated elsewhere, but actioning this one, not terribly difficult ticket
would bring big dividends to user perception.

It's been 8 years for this ticket! I think this speaks volumes in terms of the level of support that end users are going to get on snap going forward.