Hi
On 11/06/2020 20:20, Patrick Cardona via Discussion list for the GNUstep
programming environment wrote:
This my version of GNustep-base on raspbian Buster (10.4) :
gnustep-base-runtime/stable,now 1.26.0-4+deb10u1 armhf [installé, automatique]
GNUstep Base library - daemons and tools
libgnustep-base-dev/stable,now 1.26.0-4+deb10u1 armhf [installé, automatique]
GNUstep Base header files and development libraries
libgnustep-base1.26/stable,now 1.26.0-4+deb10u1 armhf [installé, automatique]
GNUstep Base library
That version should have the necessary fixes, which were made in 2018...
I am puzzled. SO if you are positive running a self-compiled GWorkspace
from GIT then you should be fine.
The situation with mount mounts is a little bit more complex and
GWorkspace tries to be smart with it. It is a little bit more complex
than what was on OpenStep perhaps and it tries to get along with
different mounting systems.
The "Classic" way is easy as follows:
- you have in /etc/fstab an entry of mount points of your interest
- if you have user permission to mount them (mount is not only for
superuser! it depends on the permission of the device node and mount
point, often you need to belong to specific groups to be able to do it.
e.g. cdrom, floppy, disk...)
- check disk will "mount it" by issuing the mount command
- to unmount it, you trash it to the bin
- to help along, you can configure with SystemPreference mount points to
be checked and considered
However, it may happen (as you are doing) that you mount something with
a console command or an automount daemon, it can be even done with
another user.
GWorkspace sometimes detects the mount automatically (thanks to
fswatcher) and if not "Check disks" should find it, even if it does not
need to mount it, since it is already there.
You still can attempt to unmount such a volume, but if it was not done
with your user, you cannot unmount it.
So... this is the general scenario, the details are a little bit tricky.
Riccardo
