Date: Sun, 19 Feb 2012 22:47:13 +0100 From: vermaden <vermaden@interia.pl> To: Hans Petter Selasky <hselasky@c2i.net> Cc: matt <sendtomatt@gmail.com>, gleb.kurtsou@gmail.com, freebsd-stable@freebsd.org, uffe@uffe.org, freebsd-hackers@freebsd.org, joe.culler@gmail.com, freebsd-current@freebsd.org, lars.engels@0x20.net Subject: Re: devd based AUTOMOUNTER Message-ID: <evbvqmovseenzzafkvdy@cufm> In-Reply-To: <201202181409.08859.hselasky@c2i.net> References: <hkubftdrahxmtuzcfqzh@ziad> <4F3EE186.4020801@gmail.com> <uhhupehcnrebtwjfedhg@xlkc> <201202181409.08859.hselasky@c2i.net>
next in thread | previous in thread | raw e-mail | index | archive | help
Hi,
sorry for late response, but I currently have quite a
lot 'weekend activities' that are definitely not near
a computer ;)
written by Gleb Kurtsou ...=20
>> __state_lock() {
>> while [ -f ${STATE}.lock ]; do sleep 0.5; done
>> :> ${STATE}.lock
>> }
>
> Why not keep it stateless, unmounting by hand would kill integrity.
The state file is needed for automatic umount of fuse-based mounts,
the device that script would be triggered will be /dev/da0 for example
while the 'virtual' device that was actually used for the mount was
/dev/fuse0, that is why I need to track what is mounted and how.
These functions are mostly to keep that 'state file' integral,
to prevent two various event writing at the file simultanously,
which would probable killed the information integrity.
Unmounting the device does not kill integrity at all, I also thought
about that, You may plug the device, do whatever You want, event
change the filesystem there and mount it again, but when You umount
it and unplug it, then the script will umount that device (yes
pointless here at this moment) and remove the entry from state file.
> Usage of `file` is a big security concern.
Can You explain why?
> I think geom config and list of mounted file systems should be
> sufficient for collecting information at runtime. Although it may not be
> that easy for disks without partitioning.
geom config?
I also make use of the list of mounted filesystems, but the problem
with fuse-based devices remain as I stated earlier.
> I'm using a python script for mounting/unmounting removable disks,
> but having similar tool written in sh would be great.
>=20
> https://github.com/glk/mmount
Thanks for sharing, maybe I will find some ideas there ;)
written by Uffe Jakobsen ...
> Nice,
Thanks.
> Instead of requiring modification to /etc/devd.conf why not just
> put a "plugin" conf-file in /etc/devd/ - well even better put in
> /usr/local/etc/devd/ - that way your devd.conf modifications are
> not lost upon patching/updating base os.
Great advice, I will do that in the next 'release' ;)
> There is an existing port called "automounter" by Dominic Fandrey
> which is much similar to your work.
Yes but its amd based.
> His "automounter" also works with disk labels
> (as found in /dev/ufs/ and /dev/msdosfs/ etc)
The labels are only 'an addition' to appearing device nodes at /dev,
Yes it would be nice to see that /dev/msdosfs/BACKUP is mounted
instead of /dev/da0s1, but I will have to make a lot of additional
check to see if that new label is part of that or other device etc.
> You should consider make a port out of your work.
I probably will try to do that, but I think it stil needs polish ;)
written by Lars Engels ...
> And please don't hardcode polish locales in mount_msdosfs :-)
I already changed that, I also plan to create simple config file,
it was just not 'the most important thing' that I was dealing
with at that time, its easy to move options into variables,
its harder to make script work the way it should ;)
But thanks for suggestion, good point.
written by Joe Culler ...
> Thanks for working on it. It works great for me, thanks!
Thanks, good to know ;)
> I have a question, could you export a fusefs-exfat or
> fusefs-ntfs share directory over NFS? I can't get it work.
> If you have a solution, please let me know, thanks.
I will try to do that tomorrow ane let You know.
Regards,
vermaden
---
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?evbvqmovseenzzafkvdy>