On Wed, 6 Apr 2005, Kevin Oberman wrote: > > Date: Tue, 5 Apr 2005 23:55:27 +0100 (BST) > > From: Robert Watson <rwatson_at_FreeBSD.org> > > > > On Tue, 5 Apr 2005, Poul-Henning Kamp wrote: > > > > > In message <20050405201820.042685D07_at_ptavv.es.net>, "Kevin Oberman" writes: > > > > > >>> It would be useful if mount was smart enough to notice when it is > > >>> dealing with a read-only device, and try to mount such things > > >>> read-only, rather than trying to mount things read-write by default and > > >>> failing. Of course, the system shouldn't panic, either. :-) > > >> > > >> I think that is what I said. I am almost sure that this is how it used > > >> to work. I'm not sure whether the change was caused by something in > > >> msdosfs or GEOM (or somewhere else), but I sure preferred it when the RO > > >> device mounted RO. CDs still do this (thankfully). This makes me suspect > > >> msdosfs is the culprit. > > > > > > There are two ways that a filesystem correctly could handle a R/O media: > > > > > > 1. Fail with EROFS unless asked t mouned read-only > > > > > > 2. Silently downgrade th emount to read-only. > > > > > > I personally prefer the first because that way a script does not have to > > > check if it got the mount it wanted or not. > > > > In general, I agree, but this will de-POLA the following command: > > > > mount -t cd9660 /dev/acd0 /cdrom > > > > I wonder if a useful middle ground is to adopt (1) above except in the > > case of perenially read-only file systems (cd9660), in which case (2) is > > adopted? > > I hate to see such inconsistency. I don't like seeing very similar > devices behaving differently for no good reason. > > I think a better idea is a new option to allow/reject demotion to > read-only when hardware does not allow writes. POLA is slight and it > lets people do what they want to do with the issue. This would also fix mounting read-only floppies (which right now causes an undead buf when the write fails). -- Doug White | FreeBSD: The Power to Serve dwhite_at_gumbysoft.com | www.FreeBSD.orgReceived on Fri Apr 08 2005 - 03:13:14 UTC
This archive was generated by hypermail 2.4.0 : Wed May 19 2021 - 11:38:31 UTC