Hi folks, I’m stumped as to why I get a write permissions error on a snap that is using the home plug. The snap is cherrytree, which is a note taking application.
The issue is that if a user has their cherrytree file in $HOME/Documents or $HOME/Downloads or similar, there’s no problem saving changes to the file. However, if the user has their cherrytree file in $HOME, there’s a write permissions error even though it does save the file:
The problem is the tmp file is being created as as a hidden file/folder. When this happens in the top level of$HOME, the home interface denies it because it can’t really tell the difference between .tmp-my-safe-file and say .X11Authority, .bashrc or .ssh/
Would it be possible to recompile the app to make write the name with something other than a dot? This would make it briefly visible but, it’s unfortunately the only applicable solution other than writing the file elsewhere entirely like /tmp or so.
Interestingly, the XDG Desktop Portals actually do take this into account to some degree and you might find e.g., if you actually removed (or disconnected) the home interface such that the portals were mandatory to mediate writing to $HOME at all, then the temp file issue goes away (because the temp file is also redirected in the documents storage path).
Ultimately the best fix would be to change the temporary files name, if it’s truly temporary, the name barely matters if it gets cleared up properly anyway. This way you’re covered for portals and non portals situations.
I believe ultimately LibreOffice and a few others suffer from similar issues. So does one of my own snaps, which means I’ve an example patch of doing the same elsewhere!
I guess you could do bonus points for detecting OS.GetEnv("SNAP") != nil or dir == OS.GetEnv("HOME"), and only adjusting the temp file for when you know it’s needed, alternatively, keep it simple and don’t overcomplicate things, the file should only really exist for a few nanoseconds anyway.
Ah ok thanks so much!!! I’ll first give it a shot without the home plug to see if portals handles it without other changes. I appreciate the suggestion
well without the home plug entirely, it doesn’t seem to force the xdg portals method of accessing $HOME. Instead I get an error message saying that there isn’t permissions to read my home directory. So I think either the temp file name will need to be changed entirely, or just for the $HOME dir.
Unfortunately the portals support isn’t guaranteed since it’s up to the toolkit to implement, but I’ve taken a look at Cherrytrees snapcraft.yaml and it looks like it explicitly overrides it to never attempt portals, with the GTK_USE_PORTAL: 0 in the build file.
It’d be worth trying this again with that removed (actually, the gnome extension implicitly sets it to 1, but I’m unsure which wins when there’s both defined, seemingly the 0 in this case), I’m assuming there might be a reason its defined. Usually the portals are transparent to the point people won’t notice them, but not always, and it’s weird to see them explicitly disabled.
Ultimately though, the reason I’d encourage simply prefering the change of name, is that even if the host doesn’t support portals (not all desktops will), the functionality should still work, so it’s a cleaner fix. That said, it could be worth encouraging reassessing why it’s explicitly disabled in CherryTree, maybe it doesn’t need to be?
Just to be clear, the reason the portals help here, is that when the path is converted into /run/user/** format, your app will typically place the temp file in the same directory. The portals will silently ignore the temporary file as it’s unexpected, whilst allowing the proper file to be written back to the real location. On the other hand, this mechanism in rare cases can cause issues for the same reason, which might be why it’s been disabled prior. Whilst the home interface is connected, the backend will go “this location is writable” and avoid using mediation, which is true for the final file, but not the temporary file, which isn’t considered.
Ok I tried by removing the home plug aaaaand forcing GTK_USE_PORTAL: 1 and that didn’t work either. I got an error: [2024-11-15 13:06:01.146] [che] [error] !! sqlite3 'CREATE TABLE node (node_id INTEGER UNIQUE,name TEXT,txt TEXT,syntax TEXT,tags TEXT,is_ro INTEGER,is_richtxt INTEGER,has_codebox INTEGER,has_table INTEGER,has_image INTEGER,level INTEGER,ts_creation INTEGER,ts_lastsave INTEGER)': database is locked
I think the real solution is removing the dot from the filename like both you Jameses have suggested
I’ll reach out to the maintainer to see if this is a possibility and thanks @jamesh for even pointing to the right place in the source code!
Shame, I think the SQLite issue is resolved in newer versions of the portals, but, given LTS releases and backports, yeah; I’d say you’d be waiting years for it to be readibly available unfortunately. Ultimately the only fix here then is to avoid the ., at least when you’re in $HOME itself, but it’s probably easier given the files are temporarily to just avoid the . everywhere and rely on them being cleaned up basically instantly. (Small possible win, if the app fails to clean them up, the fact they’re visible means the user can maybe do that themselves manually, which is easier when they’re not hiding for weeks/months/years!)
