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

Bug #1575053 reported by John Wang on 2016-04-26
This bug affects 1040 people
Affects Status Importance Assigned to Milestone
snapd
High
Zygmunt Krynicki
snapd (Ubuntu)
Wishlist
Unassigned

Bug Description

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) wrote :

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

Changed in snapd (Ubuntu):
status: New → Confirmed
Michael Vogt (mvo) on 2017-01-27
Changed in snapd (Ubuntu):
importance: Undecided → Wishlist
Stephan Henningsen (zta77) wrote :

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) wrote :

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) wrote :

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.

Changed in snapd (Ubuntu):
status: Confirmed → Opinion
Changed in snapd:
status: New → Opinion
Or Schiro (orschiro) wrote :

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

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) wrote :

@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) wrote :

@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) wrote :

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) wrote :

@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.

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

"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.

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

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. :)

Changed in snapd (Ubuntu):
status: Opinion → Confirmed
Changed in snapd:
status: Opinion → Confirmed

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.

summary: - User data directory should conform to XDG Base Directory Specification
+ Please move snap user data from "$HOME/snap" to "$HOME/.snap" (or to
+ "$HOME/.local/share/snap" in accordance with the XDG spec)
no longer affects: snappy
Stego (stegomon) wrote :

Much wanted!

Stephan Henningsen (zta77) wrote :

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) wrote :

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) wrote :

@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) wrote :

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...

tags: added: julyshakedown
larpon (larpon) wrote :

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)

d❤vid (kwill) wrote :

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) wrote :

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

monaxos (neotheo) wrote :

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) wrote :

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) wrote :

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) wrote :

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) wrote :

... "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) wrote :

"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) wrote :

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) wrote :

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

GizmoChicken (gizmochicken) wrote :

"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) wrote :

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

Chris Meyers (sulobanks) wrote :

+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) wrote :

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) wrote :

@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) wrote :

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

Fanjin Zeng (fanjin) wrote :

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) wrote :

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) wrote :

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.

Changed in snapd:
status: Confirmed → Won't Fix
Changed in snapd (Ubuntu):
status: Confirmed → Opinion
Changed in snapd:
status: Won't Fix → Opinion
importance: Undecided → Wishlist
Changed in snapd:
status: Opinion → Confirmed
Changed in snapd (Ubuntu):
status: Opinion → Confirmed
summary: - Please move snap user data from "$HOME/snap" to "$HOME/.snap" (or to
- "$HOME/.local/share/snap" in accordance with the XDG spec)
+ Please move the "$HOME/snap" directory to a less obtrusive location
John Lenton (chipaca) on 2018-03-31
no longer affects: snappy
Jeremy Bicha (jbicha) on 2018-09-26
description: updated
information type: Public → Public Security
information type: Public Security → Private Security
information type: Private Security → Public
information type: Public → Public Security
information type: Public Security → Public
Yovan (jiabanster) on 2019-12-20
Changed in snapd (Fedora):
status: New → Invalid
no longer affects: snapd (Fedora)
Zygmunt Krynicki (zyga) on 2020-04-30
Changed in snapd:
importance: Wishlist → High
assignee: nobody → Zygmunt Krynicki (zyga)
203 comments hidden view all 283 comments
bitboy (zeus557) wrote :

@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 (harry-c) wrote :

@zyga
Thank you! That's awesome!

Ty Poorman (flotts) wrote :

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) wrote :

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) wrote :

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) wrote :

@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) wrote :

@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) wrote :

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) wrote :

@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) wrote :

> 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) wrote :

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

Gustavo Niemeyer (niemeyer) wrote :

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) wrote :

>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) wrote :

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) wrote :

@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) wrote :

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) wrote :

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) wrote :

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) wrote :

> 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) wrote :

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) wrote :

> 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) wrote :

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) wrote :

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) wrote :

> 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) wrote :

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) wrote :

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) wrote :

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) wrote :

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) wrote :

> 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) wrote :

> 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) wrote :

This needs to go

2 comments hidden view all 283 comments

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,

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) wrote :

@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) wrote :

It is insane... it affects me too!

Mr Aaron J Michaux (amichaux) wrote :

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) wrote :

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 Holland (sersorrel) wrote :

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.

Displaying first 40 and last 40 comments. View all 283 comments or add a comment.
This report contains Public information  Edit
Everyone can see this information.

Duplicates of this bug

Other bug subscribers