[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-Id: <E1JFU7r-0006PK-So@pomaz-ex.szeredi.hu>
Date: Thu, 17 Jan 2008 13:45:43 +0100
From: Miklos Szeredi <miklos@...redi.hu>
To: salikhmetov@...il.com
CC: miklos@...redi.hu, linux-mm@...ck.org, jakob@...hought.net,
linux-kernel@...r.kernel.org, valdis.kletnieks@...edu,
riel@...hat.com, ksm@...dk, staubach@...hat.com,
jesper.juhl@...il.com, torvalds@...ux-foundation.org,
a.p.zijlstra@...llo.nl, akpm@...ux-foundation.org,
protasnb@...il.com, r.e.wolff@...wizard.nl,
hidave.darkstar@...il.com, hch@...radead.org
Subject: Re: [PATCH -v5 2/2] Updating ctime and mtime at syncing
> > 4. Recording the time was the file data changed
> >
> > Finally, I noticed yet another issue with the previous version of my patch.
> > Specifically, the time stamps were set to the current time of the moment
> > when syncing but not the write reference was being done. This led to the
> > following adverse effect on my development system:
> >
> > 1) a text file A was updated by process B;
> > 2) process B exits without calling any of the *sync() functions;
> > 3) vi editor opens the file A;
> > 4) file data synced, file times updated;
> > 5) vi is confused by "thinking" that the file was changed after 3).
Updating the time in remove_vma() would fix this, no?
> > All these changes to inode.c are unnecessary, I think.
>
> The first part is necessary to account for "remembering" the modification time.
>
> The second part is for handling block device files. I cannot see any other
> sane way to update file times for them.
Use file_update_time(), which will do the right thing. It will in
fact do the same thing as write(2) on the device, which is really what
we want.
Block devices being mapped for write through different device
nodes..., well, I don't think we really need to handle such weird
corner cases 100% acurately.
Miklos
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists