So looking at the current automount system, I see skidoo's very valid point that spacefm desktop will still automount if that desktop is in use.

It is possible to set spacefm to not automount from the current automount-config gui, if folks think that is something it should do.

actually, it should probably be set to"always" not automount, which I can also do.

any thoughts?

I prefer AntiX just the way it comes installed. And the auto mount get used quite a bit.

If automount is set to off I would expect it to be off in all situations. If it is set to on, then on. I may be biased in this though trying to keep consistency among the desktops via menus, startup, wallpaper utility, etc... I would consider a automount utility in the same category as the wallpaper app.

dolphin_oracle wrote:So looking at the current automount system, I see skidoo's very valid point that spacefm desktop will still automount if that desktop is in use.

I do not know where the comments were made so the following do not draw from them.

In very generalised terms the Control Centre is often seen as controling"system type" settings. In that case I would favour on/off automount to also be system wide.

I dimly recall some mention in the past of antiX scripts that would benefit from having a central control point for (un)mounting (partitioning?). Perhaps there might be an opportunity to do it now if it is still relevant.

I would prefer automount default to off, as it can get very annoying when partitioning drives ready for installing. __{{emoticon}}__

prefer [spacefm] automount default to off, as it can get very annoying when partitioning drives ready for installing

I agree -- in order to preclude confusion, spacefm automount default should be set to"off".
For me, while betatesting the live-usb-maker script, the (by default, spacefm forced automount) effect was maddening.

It is possible to set spacefm to not automount from the current automount-config gui

You've found a magic bullet? When I investigated, my takeaway was:

spacefm, when launched, reads automount directive from its preferences file.
For an"enhanced" controlCentre utility script to be effective in editing the spacefm preferences file,
it would need to"killall spacefm" before writing to the spacefm prefs file
(or refuse to proceed, prompting the user to manually close all running spacefm instances).
A further complication: detecting/handling case where"spacefm -d" is currently managing the desktop

In any event, editing that prefs file (even if it is not locked / in use) is probably inadvisable.
(fileS plural. See the list below. Separate files are referenced by sudo-launched instances of spacefm)
Careful, don't wreck the session, session-last, session-prior spacefm files!

A possible approach would be to customize spacefm's default .../hand_fs_+def pathed scripts,
but IMO that would just shift (and further compound) spacefm users' confusion regarding automount governance.

A couple of points.

1. The current automount is run by the user.

2. The space desktop runs as user.

3. I know how to customize the session files. Antix 16.1 actually ships with a customer file. It needs some tweaks for the future now that it's been in action for a while, but it's a start. There is a /etc/xdg system for distro-specific changes. You can't do everything with them, but you can do a lot.

4. I've been experimenting with just what you suggest...killing spacefm and restarting. I think I can do it without killing the session files after reading up on how they work.