On 0421T2348, Dan Partelly wrote: > Yes, you are right it misses the media change handler in devd.conf. > maybe it should bementioned somewhere in a man page if it is not > already there. Thanks for the pointer. It's mentioned in a comment in auto_master file. But yeah, mentioning it in a manual page seems like a good idea. > Anyway, if I would have written the system, what I would have done > is to consolidate both user mode daemons into one and make this > daemon a client of devd, fstyp a library, and handle all removable > media inside transparent to the user, without requiring any modifications > to devd.conf, and without relaying on shell scripts. > > Is there any reason you did not took this approach ? This is not > criticism, I am genuinely interested. Yes - I actually like shell scripts. I like being able to provide the glue in a way that's easy to debug and modify, without having to rebuild anything, so that it can be tailored to specific needs by the system administrator. In this case the problem, I think, is not with the shell scripting. It's just that it doesn't "enable itself" when needed, or isn't just enabled by default. > > and simply > > retrofit the changes back to autofs - but that hasn't happened (yet). > > Please consider doing it. A kevent on /media would allow other programs > to see how volumes come and go, and I can imagine several situations > where this can be handy. And too many directories left there do become > annoying. Well, you have devd notifications for this - and it gives you much more flexibility. > > On 21 Apr 2016, at 23:20, Edward Tomasz Napierała <trasz_at_FreeBSD.org> wrote: > > > > On 0421T1526, Dan Partelly wrote: > >> The scenario is: > >> > >> Let’s say I have autofs_enable , working with media map. > >> > >> If I have a CD in CD drive , all is well and when the system is fully booted up > >> /media contains a directory through which I can access the content of the > >> CD-ROM. Now if you eject this CD , and insert a new one, nothing happens. > >> /media does not contain a new access point for the new disk inserted in the > >> device. > >> > >> What I would expect is when I change the media in Cd-rom , a new > >> access point for the volume in question should be reated in /media. > >> > >> Perhaps this functionality is exposed differently by the automounter, > >> but them I would not expect the CDrom to be accessible at all though the > >> media map. > > > > If by "access point" you mean the directory, then it will, unless the CD > > doesn't have a label - in that case the device name will be used instead, > > and since it's the same device, it will be the same name - usually "cd0". > > > > However - I've just checked to make sure and it works the way it should. > > What you're decribing seems like you're missing the part of devd.conf(5) > > responsible for notifying autofs about media change. Do you? > > > >>> he problem here is that it's quite hard to fix, there's a risk > >>> of breaking existing functionality, and the problem is largely cosmetic. > >> > >> until you have more than 10 of them there, when it largely annoying. > >> anyway, what is the reason it is very hard to fix and it would break existing > >> functionality. can you please shed some light ? > > > > Basically, the autofs doesn't support removing the nodes. It wasn't > > really required for the usual use case, and it simplified the code a lot. > > Plan was to pick it up again with my next filesystem project, and simply > > retrofit the changes back to autofs - but that hasn't happened (yet). > > > > [..] >Received on Fri Apr 22 2016 - 06:36:50 UTC
This archive was generated by hypermail 2.4.0 : Wed May 19 2021 - 11:41:04 UTC