There have been comments/suggestions that an installed antiX should automount devices (internal and external) automatically.
Spacefm desktop does this automatically, rox-desktop does not.
Using spacefm file-manager does this automatically even when using rox-desktop.
Some users do not like have their devices automounted (especially internal)
Here are the options.
1. Do nothing and point users to docs to set up automount (present policy)
2. Default to Spacefm-IceWM
3. Default to rox-IceWM, but with spacefm as default file-manager
4. Since startup in desktop-session now has a devmon rule to open external devices (commented), use this with default rox-desktop. Have this set to open rox by default?
5. others?
topic title: automounting devices
11 posts
• Page 1 of 1
-
anticapitalista
Posts: 5,956
- Site Admin
- Joined: 11 Sep 2007
-
Posts: 2,238
- Joined: 16 Dec 2007
#2
I think the main issue is not really the automounting, its that the devices do not appear in rox-filer unless they are mounted or defined in fstab.
spacefm (and thunar in mx-15) does automount external devices, but does not automount internal devices. However, both list them in the shortcut pane on the left panels, making mounting relatively trivial. but rox-filer is blissfully unaware of external usb devices until they are mounted (no mount points).
I haven't seen the devmon rule that is included by default. Its not on beta5. But the one I posted in the wiki articile will open removable media in the default file manager as defined by desktop-defaults, which seems appropriate to me.
To me, not automounting internal devices is fine, even standard. But I think that the vast majority of people that stick a usb stick or an external usb hard drive into their port would like to see that device mounted, whether a file manager window pops open or not.
spacefm (and thunar in mx-15) does automount external devices, but does not automount internal devices. However, both list them in the shortcut pane on the left panels, making mounting relatively trivial. but rox-filer is blissfully unaware of external usb devices until they are mounted (no mount points).
I haven't seen the devmon rule that is included by default. Its not on beta5. But the one I posted in the wiki articile will open removable media in the default file manager as defined by desktop-defaults, which seems appropriate to me.
To me, not automounting internal devices is fine, even standard. But I think that the vast majority of people that stick a usb stick or an external usb hard drive into their port would like to see that device mounted, whether a file manager window pops open or not.
-
anticapitalista
Posts: 5,956
- Site Admin
- Joined: 11 Sep 2007
#3
On the lenovo s21e netbook and in VBox, space-icewm uses less RAM than rox-icewm.
I'm very tempted to set this as the default.
Should spacefm and space desktop use single or double click? Personally I prefer single click.
I'm very tempted to set this as the default.
Should spacefm and space desktop use single or double click? Personally I prefer single click.
-
Posts: 1,062
- Joined: 20 Jan 2010
#4
+1 for single click
-
Posts: 148
- Joined: 21 Apr 2011
#5
I always change to space-icewm straight after an install.
My preference is for double-click (my MS roots are showing!), but I don't think the default is too important.
Chris
My preference is for double-click (my MS roots are showing!), but I don't think the default is too important.
Chris
-
Posts: 521
- Joined: 20 Apr 2015
#6
The ease to mount internal devices has always been my complaint. But thanks to d_o's quote above, I can now get around what looked like a major insurmountable problem to me and I bet for a lot of other folks also .
Took a couple years to find that out.
Let me change what I had originally posted about automount as I had worded it wrong.spacefm (and thunar in mx-15) does automount external devices, but does not automount internal devices. However, both list them in the shortcut pane on the left panels, making mounting relatively trivial. but rox-filer is blissfully unaware of external usb devices until they are mounted (no mount points).
The ease to mount internal devices has always been my complaint. But thanks to d_o's quote above, I can now get around what looked like a major insurmountable problem to me and I bet for a lot of other folks also .
Took a couple years to find that out.
-
Posts: 1,062
- Joined: 20 Jan 2010
#7
To clarify make-fstab will make an appropriate fstab file for whatever is plugged in to the system at the time make-fstab is run correct?
So if we ran make-fstab on boot up this should give us all the internal / permanent partitions /drives a corresponding entry in fstab and therefor a mount point in rox. Is this correct?
Then if we have the devmon entry from D.O.'s Wiki entry for anything added to the system thereafter. (DVD, usb, etc)
That should follow the file manager as chosen by the user and I believe devmon is a separate package from spacefm (udevil I think) so that there is no depends on spacefm if wanting to use rox-desktop.
Maybe then a small yad utility in the control center to enable / disable both, enable / disable on boot up, enable / disable while running?
So if we ran make-fstab on boot up this should give us all the internal / permanent partitions /drives a corresponding entry in fstab and therefor a mount point in rox. Is this correct?
Then if we have the devmon entry from D.O.'s Wiki entry for anything added to the system thereafter. (DVD, usb, etc)
That should follow the file manager as chosen by the user and I believe devmon is a separate package from spacefm (udevil I think) so that there is no depends on spacefm if wanting to use rox-desktop.
Maybe then a small yad utility in the control center to enable / disable both, enable / disable on boot up, enable / disable while running?
-
Posts: 2,238
- Joined: 16 Dec 2007
#8
note that if you eliminate the --exec-on-XXX options from the devmon command, devices will still automount but no filemanager window will open.
I'm not real sure how make-fstab works (custom entries wiped out or preserved), but generally that's already been done by the live system and carries over on install anyway, especially now that the script handles internal eMMC devices.Dave wrote:To clarify make-fstab will make an appropriate fstab file for whatever is plugged in to the system at the time make-fstab is run correct?
So if we ran make-fstab on boot up this should give us all the internal / permanent partitions /drives a corresponding entry in fstab and therefor a mount point in rox. Is this correct?
Then if we have the devmon entry from D.O.'s Wiki entry for anything added to the system thereafter. (DVD, usb, etc)
That should follow the file manager as chosen by the user and I believe devmon is a separate package from spacefm (udevil I think) so that there is no depends on spacefm if wanting to use rox-desktop.
Maybe then a small yad utility in the control center to enable / disable both, enable / disable on boot up, enable / disable while running?
note that if you eliminate the --exec-on-XXX options from the devmon command, devices will still automount but no filemanager window will open.
-
Posts: 1,308
- Joined: 31 Aug 2009
#9
We don't run make-fstab on installed systems. It runs at boot-time on the live system and is run during the install process to set up the fstab file. When make-fstab is run during the install process, it only adds fstab entries for devices that are mounted under /mnt/antiX. For example, if a partition is mounted at /mnt/antiX/home then it will show up in the new fstab at /home.Dave wrote:So if we ran make-fstab on boot up this should give us all the internal / permanent partitions /drives a corresponding entry in fstab and therefor a mount point in rox. Is this correct?
-
Posts: 2,238
- Joined: 16 Dec 2007
#10
I'm thinking a script that runs no matter the desktop (maybe even without a desktop) and checks a configuration file to see if the automounting should actually happen. and a gui configuration tool something like the attached.
-
Posts: 1,028
- Joined: 21 Aug 2011
#11
Primary Goals
On a broader aspect, might auto-mounting adversely affect some antiX scripts that expect to operate without a device mounted?. Perhaps they might benefit from being checked and potentially adjusted.
This is one of those circumstances where either choice will delight some people and disappoint others. Probably the best than can be achieved is to place the focus on usability. That will enable each user to adopt whatever suits their way of working.anticapitalista wrote:Some users do not like have their devices automounted (especially internal)
Primary Goals
- Be independent of the file manager i.e. works equally with them all
- Be operated via a GUI to avoid manually editing config files
- Be managed through the Control Center to give a single point of set up for the account
- Be Documented
If number of clicks becomes relevant, my preference is for double click operation, because it is already a familiar action to a wide number of users.dolphin_oracle wrote:I think the main issue is not really the automounting, its that the devices do not appear in rox-filer unless they are mounted or defined in fstab.
spacefm (and thunar in mx-15) does automount external devices, but does not automount internal devices. However, both list them in the shortcut pane on the left panels, making mounting relatively trivial. but rox-filer is blissfully unaware of external usb devices until they are mounted (no mount points).
[...]
To me, not automounting internal devices is fine, even standard. But I think that the vast majority of people that stick a usb stick or an external usb hard drive into their port would like to see that device mounted, whether a file manager window pops open or not.
[...]
I'm thinking a script that runs no matter the desktop (maybe even without a desktop) and checks a configuration file to see if the automounting should actually happen. and a gui configuration tool something like the attached.
On a broader aspect, might auto-mounting adversely affect some antiX scripts that expect to operate without a device mounted?. Perhaps they might benefit from being checked and potentially adjusted.