This is the mail archive of the gcc@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: Linux 2.6 nanosecond time stamp weirdness breaks GCC build


On Thu, 1 April 2004 16:37:15 -0800, Andrew Morton wrote:
> 
> I think this will cause the inode timestamps to keep on creeping forwards.
> 
> How about in ext3_read_inode() you do:
> 
> 	inode->i_atime.tv_sec = le32_to_cpu(raw_inode->i_atime);
> 	inode->i_ctime.tv_sec = le32_to_cpu(raw_inode->i_ctime);
> 	inode->i_mtime.tv_sec = le32_to_cpu(raw_inode->i_mtime);
> -	inode->i_atime.tv_nsec = inode->i_ctime.tv_nsec = inode->i_mtime.tv_nsec = 0;
> +	inode->i_atime.tv_nsec = inode->i_ctime.tv_nsec = inode->i_mtime.tv_nsec = 999999999;

Coming in way too late, how about changing the other end?  Each
filesystem provides a new function that transforms high resolution
time into whatever the filesystem can store.  If the function is NULL,
we use a sane default like above.
-	inode->i_atime.tv_nsec = inode->i_ctime.tv_nsec = inode->i_mtime.tv_nsec = 0;

If the user never sees the high resolution in the first place, we
don't need to play guessing games later, after data has been flushed
from the page cache.

Jörn

-- 
The competent programmer is fully aware of the strictly limited size of
his own skull; therefore he approaches the programming task in full
humility, and among other things he avoids clever tricks like the plague. 
-- Edsger W. Dijkstra


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]