On Mon, 2015-12-14 at 14:33 -0500, Austin S. Hemmelgarn wrote: > The traditional reasoning was that read-only meant that users > couldn't > change anything Where I'd however count the atime changes to. The atimes wouldn't change magically, but only because the user stared some program, configured some daemon, etc. ... which reads/writes/etc. the file. > , not that the actual data on disk wouldn't change. > That, and there's been some really brain-dead software over the years > that depended on atimes being right (now, the only remaining software > I > know of that even uses them at all is Mutt). Wasn't tmpwatcher anoterh candidate? > This should be 'Nothing on the backing device may change as a result > of > the FS', nitpicking I know, but we should be specific so that we > hopefully avoid ending up in the same situation again. Of course, you're right! :-) (especially when btrfs should ever be formalised in a standards document, this should read like: >hard-ro: Nothing on the backing device may change as a result of the >FS, however, e.g. maleware, may directly destroy the data on the >blockdevice ;-) Chris.
Attachment:
smime.p7s
Description: S/MIME cryptographic signature
