Hi!
BTW When you "swap" to a file the mtime doesn't get updated. No one seems to
complain about that. I guess it is a rather narrow use-case though.
Actually yes, I'd like to complain.
It was not swap, it was mount -o loop, but I guess that's the same
case. Then rsync refused to work on that file... and being on slow ARM
system it took me a while to figure out WTF is going on.
So yes, we have problems with mtime, and yes, they matter.
Pavel
--
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
On Tue, 14 Jul 2015 15:13:00 +0200 Pavel Machek [off-list ref] wrote:
Hi!
quoted
BTW When you "swap" to a file the mtime doesn't get updated. No one seems to
complain about that. I guess it is a rather narrow use-case though.
Actually yes, I'd like to complain.
It was not swap, it was mount -o loop, but I guess that's the same
case. Then rsync refused to work on that file... and being on slow ARM
system it took me a while to figure out WTF is going on.
So yes, we have problems with mtime, and yes, they matter.
Pavel
Odd...
I assume you mean
mount -o loop /some/file /mountpoint
and then when you write to the filesystem on /mountpoint the mtime
of /some/file doesn't get updated?
I think it should.
drivers/block/loop.c uses vfs_iter_write() to write to a file.
That calls f_op->write_iter which will typically call
generic_file_write_iter() which will call file_update_time() to update
the time stamps.
What filesystem was /some/file on?
I just did some testing on ext4 and it seems to do the right thing
mtime gets updated.
NeilBrown
On Wed 2015-07-15 14:54:56, NeilBrown wrote:
On Tue, 14 Jul 2015 15:13:00 +0200 Pavel Machek [off-list ref] wrote:
quoted
Hi!
quoted
BTW When you "swap" to a file the mtime doesn't get updated. No one seems to
complain about that. I guess it is a rather narrow use-case though.
Actually yes, I'd like to complain.
It was not swap, it was mount -o loop, but I guess that's the same
case. Then rsync refused to work on that file... and being on slow ARM
system it took me a while to figure out WTF is going on.
So yes, we have problems with mtime, and yes, they matter.
Pavel
Odd...
I assume you mean
mount -o loop /some/file /mountpoint
and then when you write to the filesystem on /mountpoint the mtime
of /some/file doesn't get updated?
I think it should.
drivers/block/loop.c uses vfs_iter_write() to write to a file.
That calls f_op->write_iter which will typically call
generic_file_write_iter() which will call file_update_time() to update
the time stamps.
Yes, that. I'm pretty sure I seen it, but it was probably on 2.6.X
kernel... Does it make sense to try to reproduce it on the old kernel?
What filesystem was /some/file on?
Very probably VFAT.
I just did some testing on ext4 and it seems to do the right thing
mtime gets updated.
Yes, I tried here, and it seems to be ok.
Thanks,
Pavel
--
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html