On Mon, 2015-12-14 at 15:20 -0500, Austin S. Hemmelgarn wrote: > On 2015-12-14 14:44, Christoph Anton Mitterer wrote: > > 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. > But reading the file is allowed, which is where this starts to get > ambiguous. Why?
> Reading a file updates the atime (and in fact, this is the > way that most stuff that uses them cares about them), but even a ro > mount allows reading the file. As I just wrote in the other post, at least for btrfs (haven't checked ext/xfs due to being... well... lazy O:-) ) ro mount option or ro snapshot seems to mean: no atime updates even if mounted with strictatimes (or maybe I did just something stupid when checking, so better double check) > The traditional meaning of ro on UNIX > was (AFAIUI) that directory structure couldn't change, new files > couldn't be created, existing files couldn't be deleted, flags on the > inodes couldn't be changed, and file data couldn't be changed. TBH, > I'm > not even certain that atime updates on ro filesystems was even an > intentional thing in the first place, it really sounds to me like the > type of thing that somebody forgot to put in a permissions check for, > and then people thought it was a feature. Well in the end it probably doesn't matter how it came to existence,... rather what it should be and what it actually is. As said, I, personally, from the user PoV, would says soft-ro already includes no dates on files being modifiable (including atime), as I'd consider these a property of the file. However anyone else may of course see that differently and at the same time be smarter than I am. > Also, > even with noatime, I'm pretty sure the VFS updates the atime every > time > the mtime changes I've just checked and not it doesn't: File: ‘subvol/FILE’ Size: 8 Blocks: 16 IO Block: 4096 regular file Device: 30h/48d Inode: 257 Links: 1 Access: (0644/-rw-r--r--) Uid: ( 0/ root) Gid: ( 0/ root) Access: 2015-12-15 00:01:46.452007798 +0100 Modify: 2015-12-15 00:31:26.579511816 +0100 Change: 2015-12-15 00:31:26.579511816 +0100 (rw,noatime mounted,... mtime, is more recent than atime) > (because not doing so would be somewhat stupid, and > you're writing the inode anyway), which technically means that stuff > could work around this by opening the file, truncating it to the size > it > already is, and then closing it. Hmm I don't have a strong opinion here... it sounds "supid" from the technical point in that it *could* write the atime and that wouldn't cost much. OTOH, that would make things more ambiguous when atimes change and when not... (they'd only change on writes, never on reads,...) So I think it's good as it is... and it matches the name, which is noatime - and not noatime-unless-on-writes ;-) Cheers, Chris.
smime.p7s
Description: S/MIME cryptographic signature
