~/documents data wiped

[svengreb]

I've installed the app on Arch Linux from the official community repository and it for the first time. I wanted to open one of my ebooks from my ~/documents directory, but was surprised that the file chooser window was empty and switched to my terminal and was horrified to find that the whole directory was empty. I've still had some files from this directory open in one of my editors, but it also quickly realized that the target file was deleted and prompted if I#d like to save the now pending content to another file.

This is a horrible bug and applications shouldn't mess with the users XDG base/core directories at all but only specific folders configured by the user or newly created ones scoped to the application. I don't know what exactly the application tried to read/scan in my ~/documents path, but this is a no go.

I've created this issue in order to allow the maintainers to fix this or even better refactor the way the application handles data at all. I'll rollback my data from one of my automated backup snapshots, but even though some data is still lost.

Here's my setup that might help to find the bug: My ~/documents path is a symlink to another directory so maybe some app logic regarding symlinks is broken. The source directory of my symlink is located in a mounted FUSE filesystem in a directory that is being watched by my synchronization tool in order to automatically sync data with my server. This setup is quite common (maybe minus the FUSE filesystem), but I've never had any problems with it neither any other application I use.

If it requires more details feel free to ask. I hope this helps to prevent other user from being hit by this. Not everyone's setup is that "failure resistance" with automated backups and might cause them to loose all data.

[johnfactotum]

Sorry for your data loss, and thanks for reporting it.

I don't really know what could have cause this. The application only writes to com.github.johnfactotum.Foliate in the user data, config, and cache directory (which is usually ~/.local/share, ~/.config, and ~/.cache, respectively), as well as creating temporary directories (which would normally be created in /tmp; this only occurs when opening Kindle files), and it doesn't delete anything except those created temporary directories. All these operations are done through GLib.

The strangest part is that you mentioned that the problem happened right after the first launch of the application. No file I/O should happen when no file is opened (except for reading/writing GSettings configurations, and the theme config in ~/.config), as Foliate actually does not currently have any library management features at all, and it doesn't query or store any document directories.

All these are also guaranteed when using Flatpak; because of the sandbox, the application does not have file system access.

Can you reproduce it? Without a way to reproduce the problem, it would be very difficult to confirm and fix this issue.

[svengreb]

Let me correct my initial post: It happened after I opened the application for the first time and tried to open a file. The start path of the file chooser window was initially set to ~/documents. Maybe because this is defined by the application (since most user will store their ebook in this directory) or because this was the last path I've used in another application and it got stored somewhere in the GTK UI cache.

When the app uses GLib for such operations this might be a good hint to enable debug logging for more details. I've tried to reproduce the problem (ofc making sure to create a new snapshot before 😉), but without success. Maybe this is a Flatpak specific problem.

Since this is not reproducible and no logs are available feel free to close this issue. I know from my own experience that stale issues like this are not that helpful and maybe this error was scoped to my system, but I wanted to report it anyway to make sure this is known when there other users who are affected by this.

[johnfactotum]

Thanks for the clarification. Even the fact that it opened with ~/documents is kind of strange, though. At least for me, GTK file choosers always open with "Recent" or "Home" (if file history is disabled) by default, if no directory is supplied to it (which Foliate doesn't).

Since there's nothing to do, I will close this for now. Feel free to comment if anyone has any further issues or clues. (I feel kind of stupid now because I've been saying "feel free to re-open" when closing issues, not realizing that GitHub does not allow the original reporter to re-open an issue.)