Closed pyamsoft closed 9 years ago
So this bug is unique to kernel 4.2-rc1? I am not brave enough to run an early rc kernel; if it works fine under 4.1.1 I would say the problem is with the kernel, not psd, unless going from 4.1.1 --> 4.2-rc1 has significant changes in the overlayfs code.
I'm on Debian 8 (unstable / stretch, Linux 4.1.0-1-686-pae #1 SMP Debian 4.1.3-1 (2015-08-03) i686 GNU/Linux), running PSD v5.75, with overlayfs enabled..
This (or a similar) issue happened to me, although I can't reproduce it now. Chromium's profile was deleted after system restart. It happened a few times, but now I've restarted once and didn't happened.
Also, regarding backups, I see there is only one backup folder (~/.config/chromium-backup/
). Sorry to ask here, but how do I enable more backups?
The snapshot (backup) is generated when there is a symlink on the file system that is dead (ie it points to nowhere). PSD will rename the last-good copy for you when this is detected. There is no limit to how many it stores, See the man page and output of psd p
I am running PSD 5.73 from the AUR using kernel 4.2-rc1.
This issue has occurred using two different browsers, Chromium stable, and Firefox stable. When I restart my machine, my profile is deleted and both browsers act as if I am opening them for the first time, greeting me with their respective "Welcome" pages. No crashes happen in PSD, and no crashrecovery directories are created. Without fail, my profiles are erased upon the restart of my machine. Please note that this issue occurs with OverlayFS enabled. By turning the OverlayFS option off, my profile persists properly and everything works fine, as it did with kernel 4.1.
To summarize:
Enable OverlayFS in psd.conf Profile is stored properly in RAM, can start/stop service correctly. Restart machine, profile is deleted with no backup or crashrecovery directories.
Disable OverlayFS in psd.conf Profile is stored properly in RAM, can start/stop service correctly. Restart machine, profile persists as expected.
This issue seems to stems from the use of OverlayFS in PSD. Whether it is an issue with the OFS implementation in the new 4.2 kernel, or an issue with how PSD uses OverlayFS I do not know. In kernel 4.1 everything worked as expected, with or without OverlayFS enabled in psd.conf.
Please understand that this is a rather low priority issue, as PSD still works without enabling OverlayFS, and the issue itself may not even be with PSD.