YesWas the original code committed before puppy started using save folders?
Correct.by "cannot be found", I presume that you mean, the script can't find them but they are there. Perhaps though, once upon a time the save folder was directly mounted but I don't think that is the case now. Instead, I think only the partition where the savefolder resides is mounted.
Okay. I see you have a point here. I've checked more thouroughly, yes, for LiveCD and savedir, this is the case. For savefile, then br0 is a mountpoint.except that it's missing the path to the save folder, "/dpup_buster/1-07092019/dpupbuster64save" which I don't think is really a mount point (even though it is the top layer).
Correct.These are symlinks which would be a different way to get the top layer and after much head scratching, I see the issue. The issue is that the path to the save layer is different than the mount point but the mountpoint is used as the key when looking up the mounttype in the following statment:
Correct.So when we try to lookup the mounttype using the path to the save file, then it returns nothing, which breaks the gui, because the gui expects three values but it only got two values.
Most of the time we want to have a copy of the savelayer in the sandbox, otherwise you don't have /etc/resolv.conf (no network), etc etc. But that's why we have a dialog to enable the user to choose exactly which layer is to be included in the sandbox.wdlkmpx's code changes suggest the viewpoint, that for a sandbox, we don't want the save location anyway. Otherwise it isn't really a sandbox. However, this isn't true if we mount the save-layer as readonly. That way it is still a sandbox.
After thinking about it, here is my updated suggestion. The $items contains 3 fields:To fix the code we first check that mounttypes[$0] returns a value with a length greater than zero, otherwise maybe print some other value to indicate that it is not a mount point.
- path
- description
- "on"
Out of this 3 lines, only the first one ("path") is actually used in the next processing.
Our problem is because the top-layer isn't listed in /proc/mounts, the "description" part (which, for SFS, will show the SFS name, and for save-layer would normally show filesystem type (ext3, etc)) is empty. But it is not actually necessary for the rest of the processing, so my suggestion is to modify the awk code so that if mounttypes[$0] is empty, then just output something, e.g file system, or even blank.
So,
Code: Select all
print $0, mounttypes[$0], "on" Code: Select all
if (mounttypes[$0])
print $0, mounttypes[$0], "on"
else
print $0, "filesystem", "on" Code: Select all
#items="$(echo "$items" | grep "\(squashfs\|\.sfs\)")There is nothing wrong with this code.BTW, the comparison expression is wrong "else if (mode=4)" but it doesn't seem to matter (I think that this always returns true). For equality comparison it should be mode == 4.
I leave it to the maintainer or whoever is going to offer a patch to decide what to do - whether to revert and apply a new fix, or just apply a fix on to of the existing one.I don't think the fix is that hard so no need to revert the previous so called fix or call it broken.
I only suggest to rename it to -BROKEN so that people don't use it until it is fixed. If the fix can be given/applied in the next few hours then obviously no need to do so.
PS: If you offer a pull request, please make sure you fix sandbox-rw.sh too.
Amazing.
)
But Kindle is the important app for me. Why they make it so hard to install 32bit WINE on 64bit system is beyond me. It should just come as part of the 64bit version cause most people use WINE to run older 32bit apps I think. Least I do.
