filemnt can destroy savefiles.

[Phoenix]

Although generally most people wouldn't mount their own savefiles, I do this occasionally to distinguish between the savefile layer and the read-only layers in order to delete stuff, or to recover read-only files whited-out. However.. clicking twice by accident, it promptly mounted the savefile to the same loop device. So now /dev/loop3 is being used twice. And it promptly destroyed my data afterwards after rebooting to recover from this mishaps. Any suggestions to prevent this said accident again would be appreciated.

[Marv]

Oof, that hurts. I mount savefiles and also SFSs rather often, sometimes several times an hour when I'm cobbling or building, done it rather cavalierly in lots of pups over years, and I've never seen this. I tried to duplicate it copying my LxPupSc64 savefile into my savefile-less fossapup directory, renaming it and trying doubleclicking it from the running fossapup. Either I mount/unmount it with two relatively slow clicks or try two quick clicks. The quick clicks are not recognized since they are less than the doubleclick threshhold in that pup. ran e2fsck on it after the excercise and it was fine. What pup were you running? I'm running on an SSD in an 2nd gen i5 based laptop and all of my savefiles are rather smallish EXT2 at 256mb so mounts are pretty quick if that turns out to be relevant. I'm interested as filemt is one of my true workhorses.

Edit: clarify clicks

[JakeSFR]

I can reproduce it from CLI (QEmu, Xenialpup-7.5):

Prep:

1. dd if=/dev/zero of=z.2fs bs=10M count=1
2. mkfs.ext2 z.2fs
3. mount z.2fs and copy some files to it
4. unmount z.2fs

and now:

Code: Select all

filemnt z.2fs & filemnt z.2fs

Result: either everything in z.2fs gets deleted immediately or right after you run filemnt z.2fs again.

It's because z.2fs is indeed mounted twice (here: via /dev/loop2 and /dev/loop3) to the same mountpoint and when the first instace gets unmounted, filemnt does 'rm -rf' on the mountpoint, but the thing is still mounted there via the second loop. Or when the second mount fails, then it also does 'rm -rf' on the (previously mounted) mountpoint.

An ad-hoc workaround would be to replace rm -rf "$MOUNTPOINT" instances in filemnt with rmdir "$MOUNTPOINT".
A slightly less safer alternative is to check if it's a mountpoint before doing rm:

Code: Select all

mountpoint "$MOUNTPOINT" || rm -rf "$MOUNTPOINT"

Greetings!

[Phoenix]

Oof, that hurts. I mount savefiles and also SFSs rather often, sometimes several times an hour when I'm cobbling or building, done it rather cavalierly in lots of pups over years, and I've never seen this. I tried to duplicate it copying my LxPupSc64 savefile into my savefile-less fossapup directory, renaming it and trying doubleclicking it from the running fossapup. Either I mount/unmount it with two relatively slow clicks or try two quick clicks. The quick clicks are not recognized since they are less than the doubleclick threshhold in that pup. ran e2fsck on it after the excercise and it was fine. What pup were you running? I'm running on an SSD in an 2nd gen i5 based laptop and all of my savefiles are rather smallish EXT2 at 256mb so mounts are pretty quick if that turns out to be relevant. I'm interested as filemt is one of my true workhorses.

Edit: clarify clicks

I am using bionicpup64 8.0, with a different kernel. (It's a kernel merge between 5.10-ck and 5.10 aufs)
Although I really don't know how it managed to use /dev/loop3 twice.

[Marv]

@JakeSFR

Reproduced from CLI per your post in my minimized fossapup64 9.5 install. The rmdir "$MOUNTPOINT" substitution works there also. Almost all of my work is on laptops with no real doubleclick capability but I am building a pup for a friends desktop so I'll see how it behaves (non CLI) on that box with a mouse with actual doubleclick capability.

Thanks,

[jfw01]

Is there a preferred locking scheme for puppy applications?

Barry's Simple Network Setup (/usr/local/simple_network_setup/sns in fossaPup32) searches ps output at about line 56. I could also imagine schemes which involve exec-ing a well-known file open, and then using lsof or fuser to count the number of processes that have it open.

If there is a preferred scheme, then there is an option where all of the copies of the mounter use it to mutually-exclude from each other, so that there are never two mounters mounting the same image at the same time. How does that appeal to people, as a way forward?

Edit:
Windows and their process IDs can be discovered with wmctrl -lp. That process ID will often be the child of the shell that participates in the mutual exclusion. There could become a convention to switch to the thing that you are mutually exlcuded against, which is possible with wmctrl -ia WIN, where WIN is the first column in the discovery output. That convention would require a plan for breaking symmetry between the two processes, so that only one of them did the switch.