Yes, I tracked it down to /usr/sbin/sfs_load removing whiteout files. My proof of concept was much simpler, I simply commented out the line in /usr/sbin/sfs_load that calls "cleanwhite".SFR wrote:Hmm, problem with disappearing whiteout files again?
This is bit of a problem, because if you add an extra sfs, all whiteout files are removed every time, sfs_load loads the sfs, which is every boot.
If you delete a file that requires a whiteout file, then re-boot, the file comes back again. Not good.
When extra sfs's were loaded in init, at least the "cleanup" only mucked things up when the extra list was changed, not every boot.
It also confuses "Boot Manager"->"Startup apps", because you end up with both a ".desktop.bak" file and the old ".desktop" file in /root/.config/autostart.
I'm intend to stick with no whiteout file cleaning, for a while.
I wonder if we would be better off if sfs_load did not do any whiteout file cleaning, and we had a utility that would remove any whiteout files that correspond to files in the specified sfs?
Or, sfs_load becomes even more sophisticated:
1) Only does a whiteout file cleanup when the list of sfs's changes, or ideally only the first time an sfs is loaded.
2) Only removes whiteout files that correspond to files that exist in the sfs being loaded.
Puppy should not make it impossible to "delete" a file that exists in an sfs.
gyro