Date: Thu, 21 Apr 2016 15:26:02 +0300 From: Dan Partelly <dan_partelly@rdsor.ro> To: =?utf-8?Q?Edward_Tomasz_Napiera=C5=82a?= <trasz@FreeBSD.org> Cc: freebsd-current <freebsd-current@freebsd.org> Subject: Re: [CFT] packaging the base system with pkg(8) Message-ID: <30F6CCDE-E099-49EF-9A1A-68F147FBF50B@rdsor.ro> In-Reply-To: <20160421095706.GA57206@brick> References: <E1asbZj-0003Ra-Qs@rmm6prod02.runbox.com> <76093.1461096570@critter.freebsd.dk> <5716AD65.8070007@shrew.net> <BF66EA01-E073-45F0-8F9E-22D57E8871B0@bsdimp.com> <5716FA70.4080604@freebsd.org> <571765BB.3050908@quip.cz> <79117ce18bd3332c7df3e55e12a161b4@rdsor.ro> <20160421095706.GA57206@brick>
next in thread | previous in thread | raw e-mail | index | archive | help
The scenario is: Let=E2=80=99s 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=20 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=20 device. =20 What I would expect is when I change the media in Cd-rom , a new=20 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=20= media map.=20 =20 > 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 ? =20 > Huh, never heard about that. I'd expect the existing mechanism to = handle > that case just fine. Could you submit a PR? > On 21 Apr 2016, at 12:57, Edward Tomasz Napiera=C5=82a = <trasz@FreeBSD.org> wrote: >=20 > On 0420T1545, dan_partelly wrote: >=20 > [..] >=20 >> Another example is the autofs mounter. The prject was marked as = complete >> by FreeBSD foundation in 2014. Last I tried it to autmount removable >> devices, it left directory after directory in the autofs managed = directory. >> This is known behavior. >=20 > Yup. The problem here is that it's quite hard to fix, there's a risk > of breaking existing functionality, and the problem is largely = cosmetic. >=20 >> It also did not worked as it should ??? (show it >> manage removable media correctly ) changing CD/DVD media disks. = Presumably >> In could have somehow manage it to work by making yet another = scaffolding >> of scripts as a questionable glue between devd and automounters. = That if >> devd receives media change notifications. I dont know. If not I could = patch >> the kernel, yeah. But it is just much to simple to not bother at all = and >> use OSx.=20 >=20 > Huh, never heard about that. I'd expect the existing mechanism to = handle > that case just fine. Could you submit a PR? >=20 > [..] >=20 > _______________________________________________ > freebsd-current@freebsd.org mailing list > https://lists.freebsd.org/mailman/listinfo/freebsd-current > To unsubscribe, send any mail to = "freebsd-current-unsubscribe@freebsd.org"
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?30F6CCDE-E099-49EF-9A1A-68F147FBF50B>