I'm also confused about the expected settings of
XDG_{CACHE,CONFIG,DATA}_HOME in a snap and their relationship(s) to
SNAP_USER_{COMMON,DATA}. Unfortunately, chromium isn't a good example to
disentagle them. Chromium (or chrome) doesn't seem to respect these
values either.
Rather than state what
Thank you, Olivier. After spending an afternoon analyzing backups, I
arrived at a similar conclusion and decided that adding an exclude
pattern
*/chromium/*/*Cache
in addition to the one that excludes */.cache is going to be the right
thing to do to solve our immediate problem.
--
You
As previously discussed, this issue is twofold:
- upstream chromium stores parts of its cache in the profile folder
(that's https://bugs.chromium.org/p/chromium/issues/detail?id=1106754)
- the snap format enforces that apps' cache folder is under
$HOME/snap/$SNAP_NAME/common/.cache
The first
@~malakai1197
You're out of luck really, switch distributions that don't use half-
baked snaps. Maintainers think that this usability regression is an
"opinion" and that tells really more than enough.
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is
Please see comment #20.
My online backup set specifically excludes $HOME/.cache (the default or
unset value of $XDG_CACHE_HOME) to avoid churning backup snapshots with
transient application cache data.
I don't know if chromium ever respected $XDG_CACHE_HOME (it would appear
from the bug report
Also run into this issue. I used to exclude cache data from backups by
simply excluding $HOME/.cache . Since the introduction of Snap apps, I
have the troublesome task to exclude every .cache folder per snap app
separately in the backup script. Especially with apps like Spotify it is
necessary for
> Bug reports should stick to fact, using wording like 'Snap-mangled'
I'm sorry, that's factually what happened. Should I have worded it Snap-
disfigured, Snap-distorted, Snap-impaired or Snap-wrecked instead?
> isn't appropriate and not a basis for any discussion.
I have **never** had any
Thank you for your bug report but to maintain a respectful atmosphere,
please follow the code of conduct - http://www.ubuntu.com/project/about-
ubuntu/conduct. Bug reports are handled by humans, the majority of whom
are volunteers, so please bear this in mind.
Bug reports should stick to fact,
** Changed in: chromium-browser
Status: New => Invalid
** Changed in: chromium-browser (Ubuntu)
Status: New => Opinion
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1887804
Title:
Just to be sure you didn't miss a few facts here as you really like to
rub it under people's noses:
* Snap mangles Chromium's configuration directory
* Snap-mangled Chromium configuration directory is not backupable
* Snap-mangled Chromium configuration directory is not compliant with
the de
> Anything else has little objective value.
That's just your opinion.
> That's not an assumption, it's a fact: https://snapcraft.io/docs
/installing-snapd.
It's an assumption, there are a lot of distributions that stay away from
snap.
> Most (average) users don't care about packaging formats
*** This bug is a duplicate of bug 1575053 ***
https://bugs.launchpad.net/bugs/1575053
> `$XDG_CONFIG_HOME/$SOFTWARE_NAME` is the de facto way
That's different from "does not follow the XDG base directory specification".
A specification (hopefully) is unambiguous. Anything else has little
> I don't think the specification¹ mandates how folders should be
structured under $XDG_DATA_HOME and $XDG_CONFIG_HOME.
`$XDG_CONFIG_HOME/$SOFTWARE_NAME` is the de facto way, snap ignores it.
Technically, yes, you're absolutely free to use hashes instead of your
software's name when you store
I don't think the specification¹ mandates how folders should be
structured under $XDG_DATA_HOME and $XDG_CONFIG_HOME. Or is there a
follow-up specification that does that?
Hopefully snapd behaves (mostly) the same on all supported
distributions, so distro-hopping shouldn't be a concern either.
> How so?
The actual software of which the configuration belongs to is chromium
(or "notes"), not snap, snap is "just there" in the middle.
Say I want to wipe snap's configuration, I should be able to wipe
`$XDG_DATA_HOME/snap` without losing my n+1 snap application's data.
Very simply put,
> That's still incorrect.
How so?
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1887804
Title:
chromium-browser does not follow XDG base directory specification
To manage notifications about this
> 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".
That's still incorrect.
> As to comment #6, can you elaborate on how you copied the existing
profile?
Thanks for the upstream bug, I'll be following it closely.
Regarding the other half of the problem (XDG base directory
specification compliance), bug #1575053 does say this in its
description:
Therefore snap packages should base the value of SNAP_USER_DATA on
the value of XDG_DATA_HOME (or
Oh and I didn't confirm my own bug, that was done by the janitor because
someone else felt that this affects them, I just restored the previous
status.
** Also affects: chromium-browser
Importance: Undecided
Status: New
--
You received this bug notification because you are a member of
I also have to repeat that currently, copying over the folder contents
you mentioned did NOT result in a working instance of Chromium. All of
my extensions broke, databases failed to open, the common folder is just
incomplete and needs attention. Please do try it yourself.
That absolutely 100%
Upstream bug report that would resolve a half of this issue:
https://bugs.chromium.org/p/chromium/issues/detail?id=1106754
Just to summarize what's left broken by this specific Ubuntu package:
* Config and cache are not in the folders defined by the base
directory specification
* Current
> You're right, it does contain cache data. That would be an upstream
bug, can you please file it at
https://bugs.chromium.org/p/chromium/issues/entry ?
I will
> I just found bug #1575053 which looks very similar to your issue, so
I'm going to mark it as duplicate, and I encourage you to read
*** This bug is a duplicate of bug 1575053 ***
https://bugs.launchpad.net/bugs/1575053
Please do not confirm your own bugs.
> Change the folder it's confined to.
As I explained earlier it's a security feature implemented by snapd, the
chromium snap doesn't get to choose where its data is
> The chromium snap is strictly confined, and that means that it cannot
read/write to hidden directories inside the user's home folder (such as
$HOME/.config or $HOME/.cache).
Change the folder it's confined to.
> That one is stored in $HOME/chromium/common/.cache/
No, not really. The profile
The chromium snap is strictly confined, and that means that it cannot
read/write to hidden directories inside the user's home folder (such as
$HOME/.config or $HOME/.cache). That's a security feature to prevent
snap applications from reading other applications' data.
Instead, as you've found out,
Status changed to 'Confirmed' because the bug affects multiple users.
** Changed in: chromium-browser (Ubuntu)
Status: New => Confirmed
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1887804
26 matches
Mail list logo
