Very low granularity of file modification timestamps
Affects | Status | Importance | Assigned to | Milestone | |
---|---|---|---|---|---|
linux (Ubuntu) |
Expired
|
Medium
|
Unassigned |
Bug Description
The lastest Lucid Lynx kernels generate file modification timestamps with a precision of merely 0.5 seconds on filesystems which support a much higher timestamp resolution, e.g. ext4 or tmpfs. In other words, the test command
{ while true; do echo >t; ls --full-time t; rm t; done; } | uniq
prints exactly two lines per second.
It seems that this bug has been introduced with kernel 2.6.32-45.
I'm able to reproduce it on three platforms:
- a HP desktop PC with Ubuntu Lucid Lynx x86_64 Desktop Edition
- a VirtualBox VM on OS X with Ubuntu Lucid Lynx x86_64 Desktop Edition
- a VirtualBox VM on OS X with Ubuntu Lucid Lynx x86_64 Server Edition
The affected kernels include the latest Lucid Lynx kernels:
2.6.32-45-generic, 2.6.32-46-generic, 2.6.32-47-generic, and 2.6.32-47-server are affected.
2.6.32-45-server and 2.6.32-46-server most likely as well.
The kernels 2.6.32-44-generic and 2.6.32-38-server are fine, 2.6.32-44-server most likely as well. (Fine is this context meaning that the provided test command prints exactly 100 unique timestamps per second when run on these kernel versions.)
I discovered this bug while giving Subversion 1.8 RC2 a try. One test case kept failing due to Subversion's unfortunate assumption that sleeping for one millisecond would be enough to get different timestamps afterwards, combined with the low 0.5 seconds granularity of modification filestamps described in this report. (Please see thread http://
IMHO this bug has a good chance of affecting other version control systems as well, because many rely on changed timestamps to recognize modified files.
This bug is missing log files that will aid in diagnosing the problem. From a terminal window please run:
apport-collect 1185730
and then change the status of the bug to 'Confirmed'.
If, due to the nature of the issue you have encountered, you are unable to run this command, please add a comment stating that fact and change the bug status to 'Confirmed'.
This change has been made by an automated script, maintained by the Ubuntu Kernel Team.