Issue with Rox window when unmounting a partition

[radky2]

Testing a new (Aug 12, 2018) Woof-CE build of Dpup Stretch 7.5, including the latest woodenshoe-wi/rox-filer of Aug 11, 2018.

When mounting a desktop disk partition by left click, the Rox window launches and properly displays the partition contents.

If I unmount this partition, the Rox window remains open but the contents disappear.

If I then manually close the empty Rox window and subsequently mount the same partition, the new Rox window is still empty and I must click the rescan button to show the contents of that partition.

Is the above scenario normal behavior?

Must I remember to manually close the Rox window before unmounting, or should the window automatically close when I unmount the corresponding partition?

[wdlkmpx]

You're probably not using an up to date Packages-puppy-stretch-official (the rox-filer entry was removed)

Or you're using a custom rox-filer.. which is not rox-filer-8woodenshoe

http://distro.ibiblio.org/puppylinux/pet_packages-common32/rox-filer-8woodenshoe-i686_common32.pet http://distro.ibiblio.org/puppylinux/pet_packages-common64/rox-filer-8woodenshoe-x86_64_common64.pet

I guess that rox-filer is open to changes if someone wants to add a patch..

After these changes i guess there will be a reaction, and i will be laughing hysterically.. i guess that's why i'll just add many other big changes.. releases can happen in 2019 ahahaha

I'm trying to make rootfs-skeleton somewhat filemanager-agnostic .. and all those rox -XXX commands don't help ..

In also intend to make some apps less intrusive and completely optional (xkbconfigmanager, keymap-set, etc), right now they're overriding stuff every time X starts, i guess this is bad for someone using LXDE for example .. and so on ..

[radky2]

wdlkmpx,

Thanks for your many improvements to Woof-CE.

For me, reverting the following commit of Aug 12, 2018 resolved my problem with Rox when unmounting a partition.

https://github.com/puppylinux-woof-CE/woof-CE/commit/37973fce94d29c4ac5c67199b75abd1568cb819b

[wdlkmpx]

But what rox version are you using? You're obviously not using the one certified by me... https://us.123rf.com/450wm/123vector/123vector1406/123vector140600007/28958482-vector-illustration-of-red-certified-stamp-on-white-background.jpg?ver=6

I can certainly revert that commit, it would go against my vision, vision is important... But i can certainly revert it this weekend.

By the way @woodenshoe , i crashed rox-filer-woodenshoe and X in upupbb

Steps to reproduce:

• Right click on window titlebar, select Move -- that's enough

(gsettings-data-convert:7340): GConf-CRITICAL **: 19:39:35.710: gconf_engine_get_local_for_addresses: assertion 'addresses != NULL' failed /usr/bin/xinit: connection to X server lost

waiting for X server to shut down XIO: fatal IO error 11 (Resource temporarily unavailable) on X server ":0" after 46 requests (45 known processed) with 0 events remaining. (II) Server terminated successfully (0). Closing log file.

This doesn't happen in dpup stretch, i also get kernel errors in upupbb in this old machine and pup_event_backend is killed a lot of times by udev... so this is issue is probably not important, unless you manage to crash it too (in upupbb).

I must say that the old rox crashes as well in this machine (upupbb) following the same steps.. i noticed that months ago, but it didn't matter then.. at all

i'd attempt to fix it, but rox is very unorthodox when it comes to compiling. If you can make it compile without doing weird stuff, like zero install or something, it would be nice

And i don't think it's an important issue unless it happens in other (newer) machines, that would probably mean that maybe a special build for upupbb is needed (but it looks like a general incompatibility with upupbb)

[radky2]

Hi wdlkmpx,

I observe the Rox problem (described above for Dpup Stretch 7.5) when building with your original Rox pet: http://distro.ibiblio.org/puppylinux/pet_packages-common32/rox-filer-8woodenshoe-i686_common32.pet

and also with my patched compilation of woodenshoe's source. The patch is minimal and simply moves the default location of the 'Last Modified' column to a position between the Size and Permissions columns in the List view.

If I revert https://github.com/puppylinux-woof-CE/woof-CE/commit/37973fce94d29c4ac5c67199b75abd1568cb819b, this fixes the Rox problem (for me) when I build with your original Rox pet or if I later build with my patched Rox pet.

[wdlkmpx]

Hmm you're right. I was using the pcmanfm desktop and only manually ran roxfiler to test a bit. However i was using the rox desktop in upupbb.. to test a bit

It does work as expected in upupbb, slacko14 and probably all the slackos and upups

Issues with some complex gtkdialog apps, issues with the ppm, rox refuses to close the window. There's something wrong with dpup

[woodenshoe-wi]

By the way @woodenshoe , i crashed rox-filer-woodenshoe and X in upupbb

Steps to reproduce:
- Right click on window titlebar, select Move -- that's enough

I was able to reproduce the problem in upupbb and my xenialpup build but not tahr... using geany instead of rox-filer so I do not believe the problem is with rox-filer...

When I was testing the option to automatically close windows when the directory goes away, sometimes the window didn't close but I could not reliably reproduce the problem.

i'd attempt to fix it, but rox is very unorthodox when it comes to compiling. If you can make it compile without doing weird stuff, like zero install or something, it would be nice

I don't know anything about zero install, for testing I just compile it with ./AppRun --compile the first time and then open a terminal in the 'build' directory that was created and run make every time I make a change to the source code. Then I run ./AppRun -n to test the new version.

The filer window will only close automatically if the directory it is showing goes away, if you unmount something did you rmdir the empty mount point?

The newer pets use a change suggested by jun7, does the problem with the windows not closing still occur with these older revision pets?
32 bit version https://www.dropbox.com/s/7xpy3m3nlhmqna8/rox-filer-standalone32-woodenshoe-5.pet?dl=1
64 bit version https://www.dropbox.com/s/yghhwqcwejqwils/rox-filer-standalone64-woodenshoe-5.pet?dl=1

[wdlkmpx]

It doesn't work, either

The problem in dpup is that once the operation fails, you mount and unmount the same partition and no files appear. It's like something got locked. You close the window and mount and unmount again.. the problem persists

But dpup exhibits some bugs that are not reproducible in the upups.. so it might a dpup issue, maybe some conflicting pkgs that are both installed..

[woodenshoe-wi]

Good, I was worried that the problem could have slipped in when I changed to the simpler approach that jun7 had suggested.

Maybe the problem has something to do with inotify?

Could you try jun7's fork? Jun7 switched from inotify to gfilemonitor.
https://github.com/jun7/rox-filer/commit/af6888f04b4cc75259de4973cdc8a28771f6e78b

[wdlkmpx]

jun7's fork compiles and behaves the same. the problem must be somewhere in dpup.

jun7's fork doesn't compile in precise puppy (and slacko14.0.. both are from 2012), i patched it to compile in precise and saw a rox-filer window with a gray background.. it's happening again but in dpup stretch (2017)

the only redeeming quality in rox.. retro compatibility is not possible. i remember compiling the latest version of pcmanfm and lxde apps in slacko 13.37 (2011), they all worked fine. the lxde guys are neglecting some apps (lxrandr), but they're mostly patched and up to date, specially pcmanfm with many enhancements.. to have something like that working fine in a very old system... the definition of stellar

that fork is doomed. something wrong with that fork.

on another note, i think it's jwm what causes the crash in upupbb... i know there are unresolved issues. so maybe only the latest revision should be used.

i thought technosaurus' version with tiny image loaders statically linked could be the solution, but the binary just crashes every time. math errors or something, it's not easy to rebase that old code (2015) or update the image loaders. i have many other priorities. so overall there's something to fix

[woodenshoe-wi]

Well, thanks for testing it.

There had been a problem that if a directory was recreated after having been deleted the inotify connection was broken. I fixed it by adding a "reconnection" function for inotify and jun7 fixed it by switching to gfilemonitor.

I guess that rules out gfilemonitor as a solution.

Empty directories do have a strange background in the jun7 fork, that is normal.

[peabee]

By the way @woodenshoe , i crashed rox-filer-woodenshoe and X in upupbb Steps to reproduce:

• Right click on window titlebar, select Move -- that's enough

Crash only happens if no window has been moved using drag&drop prior to attempting the right-click move....drag&drop move a window and all is fine.... so that's why its never been reported!! Also applies to all windows not just rox-filer Only builds UPupBB and LxPupUBB are affected - LxPupSc is fine even if you change desktop from LXDE to JWM and do a right-click move.

[wdlkmpx]

This seems to be fixed in my latest build, i wonder what fixed it

[wdlkmpx]

Hmm actually, it's not fixed, i tested the wrong script haha

[radky2]

• BUILD_FROM_WOOF='testing;021355f8;2018-11-24 12:15:35 +0800' • rox-filer-13woodenshoe-i686_common32

---

The problem described in the first post of this thread is again seen in a new (2018-11-24) Woof-CE build of Dpup Stretch 7.5:

Using the default ROX desktop, when I mount a disk partition by left click of the corresponding desktop drive icon, the Rox-Filer window launches and properly displays the partition contents.

If I unmount this partition, the Rox window remains open but the contents disappear.

If I then manually close the empty Rox window and subsequently mount the same partition, the new Rox window is still empty and I must click the rescan button to show the contents of that partition.

[woodenshoe-wi]

@radky2 could you post a link to an iso?

I remember having some similar problems when I was testing ROX-filer, but they were very intermittent and I couldn't reproduce them reliably.

I don't know if the problem is a bug in ROX-filer or something going wrong with inotify, but it would be easier to investigate if I can reproduce the problem reliably.

[radky2]

@woodenshoe-wi,

The link below provides a preliminary testing iso of Dpup Stretch 7.5 RC4, not yet released.

EDIT: iso deleted: thanks woodenshoe-wi

• BUILD_FROM_WOOF='testing;021355f8;2018-11-24 12:15:35 +0800' • rox-filer-13woodenshoe-i686_common32

Prior to Woof-CE of 2018-11-24, clicking a desktop drive icon to mount or unmount a partition worked correctly in In Dpup Stretch 7.5.

Please let me know when you download, then I can remove the testing iso from smokey01.com.

Thanks

[woodenshoe-wi]

Thanks.

I downloaded the iso and checked it against the md5, so you can delete it now.

I will investigate what is happening.

[woodenshoe-wi]

The first part of the problem is caused by the mount point not being deleted when unmounted, the second part of the problem is that ROX-filer isn't noticing when something is mounted on what ROX-filer thinks is an empty directory.

Does this change to frontend_rox_funcs fix it? https://github.com/woodenshoe-wi/woof-CE/commit/b6997a02f09d1474c5a000b33ad42303673daef3

I am not an expert on the Puppy scripts, so this change is more of a suggestion/idea on how to fix the problem and I have not merged it to testing.

It seems to fix both parts of the problem in my tests.

[radky2]

woodenshoe-wi,

Your proposed fix for frontend_rox_funcs is working very nicely in Dpup Stretch.

Thanks for your quick response!

[woodenshoe-wi]

I'm not sure if there will be any unintended consequences from automatically deleting unused mount points in /mnt, so I will leave it to @wdlkmpx to decide if it is the best solution, but the alternative is the old way of signaling ROX-filer to close any open windows from the unmount function and I think wdlkmpx was trying to get away from that approach.

[wdlkmpx]

I was using pcmanfm with the rox desktop. I always forget to make rox the default file manager to test this stuff. woodenshoe-wi's fix is mostly ok, but it can be a be improved a bit:

mount | grep -q "${MNTPT} " || umVAL=0 #not mounted

mount | grep -q " ${MNTPT} " || { rmdir "${MNTPT}" 2>/dev/null umVAL=0 #not mounted } This fixes the issue, but once the abnormal behavior has been triggered, you must restart X..

[woodenshoe-wi]

I'm not sure what the consequences are if the mount point isn't in /mnt

I definitely could have missed some extra cases, since I am not familiar with the scripts.

[wdlkmpx]

frontend_rox_funcs - unmount_func() [drive_all]

Well, this is only triggered when you click on "a close-box of mounted partition", and it definitely only happens in the rox desktop.

All other scripts that unmount stuff still need rox -D, and indeed they have rox -D, it was an accident that i removed rox -D from drive_all in recent changes

Rebasing stuff sometimes produces unwanted results.

frontend_rox_funcs - rox_umount() - called by /sbin/umount is a more generic function.. i think the code to delete the unmounted mountpoint should go there.

the rox stuff was scattered in many scripts, basically everything has been moved to /usr/local/pup_event/frontend_rox_funcs .. and this script does nothing if ROX-Filer is not running.

By deleting that file (frotend_rox_funcs) you get a different behavior suitable for other desktop environments

[woodenshoe-wi]

If all the rox related stuff is now in frotend_rox_funcs, and removing rox -D was an accident, maybe it would be safer to put the rox -D stuff back in frotend_rox_funcs instead of deleting empty mount points?

I think the mount points in /mnt are automatically created, but I don't know if unmount_func() could be called on a custom user made mount point, and it could be confusing if mount points automatically disappear.

[wdlkmpx]

I removed 'rox -D' from all rootfs-skel scripts, only frontend_rox_funcs->rox_umount() has it

But there's a little problem. In dpup stretch, the directory must be deleted otherwise the bug happens again. rox -D only closes the window, but an empty window appears the next time the partition is mounted.

So, what does this mean? rox_mount() should call rox -x .. ?

[wdlkmpx]

It should be fixed now

• Rox window is closed if mntpnt was unmounted
• A wrapper script (defaultfilemanager_x) is called from several key scripts, that way 'rox -x dir dir' fixes issues .. in filemnt, drive_all, pupcamera, etc ...

[woodenshoe-wi]

So, what does this mean? rox_mount() should call rox -x .. ?

It might be unavoidable... from http://man7.org/linux/man-pages/man7/inotify.7.html

   If a filesystem is mounted on top of a monitored directory, no event
   is generated, and no events are generated for objects immediately
   under the new mount point.  If the filesystem is subsequently
   unmounted, events will subsequently be generated for the directory
   and the objects it contains.

Bionicpup64-7.9.7 also has this problem, so it is not specific to Dpup Stretch.

I tested the jun7 ROX-filer and it had similar problems, so I don't think switching to GFileMonitor would fix it...

[woodenshoe-wi]

Maybe I spoke too soon about GFileMonitor...

Testing the jun7 ROX-filer again, it works sometimes but then stops working properly... kind of intermittent, but it must be possible then.

[wdlkmpx]

Well commit https://github.com/puppylinux-woof-CE/woof-CE/commit/e52712391966d91c2426d70072515fe35e5babab certainly fixes all possible issues

I suggest 2 new key bindings:

Display->Refresh: F5 New->Directory: Insert

[woodenshoe-wi]

New key bindings are in version 14, http://www.murga-linux.com/puppy/viewtopic.php?p=1011782

I switched to GFileMonitor but it is still a bit buggy, so I think it is best to keep using rox -x

If you mount a partition and quickly unmount it again before it is finished updating it gets messed up.