Determine file system timestamp precision
File timestamps precision is limited to one second for EXT3, one microsecond for UFS, and one nanosecond for EXT4 (at least according to experience). Is there any way to determine this based only on filesystem info?
The hacky alternatives I can think of are either to limit all my unit tests to seconds (which I do now), or to touch a bunch of files and checking which digits are zero in stat -c %x.
filesystems timestamps
asked Apr 19 '11 at 7:01
l0b0
27.7k17114242
add a comment |
File timestamps precision is limited to one second for EXT3, one microsecond for UFS, and one nanosecond for EXT4 (at least according to experience). Is there any way to determine this based only on filesystem info?
The hacky alternatives I can think of are either to limit all my unit tests to seconds (which I do now), or to touch a bunch of files and checking which digits are zero in stat -c %x.
filesystems timestamps
asked Apr 19 '11 at 7:01
l0b0
27.7k17114242
3
What you're asking about is precision, not accuracy. Your filesystem can say that a file's mtime is 2000000000.000001, but if your friendly neighborhood stratum 0 NTP clock says that it's actually 1500000000.000001 then you aren't very accurate even though you are precise to the microsecond.
– Mike S
Jan 31 '17 at 16:18
Careful: the ext4 on-disk format stores times in nanoseconds, and you can store times with that precision using utimes(), but the clock source the kernel uses to set atime/mtime/ctime is not that precise--e.g. ext4 uses current_time(), which uses current_kernel_time(), which is HZ/second granularity. (Probably about a millisecond--depending on your distro you may be able to figure out the value of HZ from 'grep CONFIG_HZ /boot/config-*')
– Bruce Fields
Feb 12 '18 at 15:40
add a comment |
File timestamps precision is limited to one second for EXT3, one microsecond for UFS, and one nanosecond for EXT4 (at least according to experience). Is there any way to determine this based only on filesystem info?
The hacky alternatives I can think of are either to limit all my unit tests to seconds (which I do now), or to touch a bunch of files and checking which digits are zero in stat -c %x.
filesystems timestamps
asked Apr 19 '11 at 7:01
l0b0
27.7k17114242
File timestamps precision is limited to one second for EXT3, one microsecond for UFS, and one nanosecond for EXT4 (at least according to experience). Is there any way to determine this based only on filesystem info?
The hacky alternatives I can think of are either to limit all my unit tests to seconds (which I do now), or to touch a bunch of files and checking which digits are zero in stat -c %x.
filesystems timestamps
filesystems timestamps
asked Apr 19 '11 at 7:01
l0b0
27.7k17114242
asked Apr 19 '11 at 7:01
l0b0
27.7k17114242
edited Jan 31 '17 at 19:25
asked Apr 19 '11 at 7:01
l0b0
27.7k17114242
asked Apr 19 '11 at 7:01
l0b0
27.7k17114242
asked Apr 19 '11 at 7:01
l0b0
27.7k17114242
27.7k17114242
3
What you're asking about is precision, not accuracy. Your filesystem can say that a file's mtime is 2000000000.000001, but if your friendly neighborhood stratum 0 NTP clock says that it's actually 1500000000.000001 then you aren't very accurate even though you are precise to the microsecond.
– Mike S
Jan 31 '17 at 16:18
Careful: the ext4 on-disk format stores times in nanoseconds, and you can store times with that precision using utimes(), but the clock source the kernel uses to set atime/mtime/ctime is not that precise--e.g. ext4 uses current_time(), which uses current_kernel_time(), which is HZ/second granularity. (Probably about a millisecond--depending on your distro you may be able to figure out the value of HZ from 'grep CONFIG_HZ /boot/config-*')
– Bruce Fields
Feb 12 '18 at 15:40
add a comment |
3
What you're asking about is precision, not accuracy. Your filesystem can say that a file's mtime is 2000000000.000001, but if your friendly neighborhood stratum 0 NTP clock says that it's actually 1500000000.000001 then you aren't very accurate even though you are precise to the microsecond.
– Mike S
Jan 31 '17 at 16:18
Careful: the ext4 on-disk format stores times in nanoseconds, and you can store times with that precision using utimes(), but the clock source the kernel uses to set atime/mtime/ctime is not that precise--e.g. ext4 uses current_time(), which uses current_kernel_time(), which is HZ/second granularity. (Probably about a millisecond--depending on your distro you may be able to figure out the value of HZ from 'grep CONFIG_HZ /boot/config-*')
– Bruce Fields
Feb 12 '18 at 15:40
3
3
What you're asking about is precision, not accuracy. Your filesystem can say that a file's mtime is 2000000000.000001, but if your friendly neighborhood stratum 0 NTP clock says that it's actually 1500000000.000001 then you aren't very accurate even though you are precise to the microsecond.
– Mike S
Jan 31 '17 at 16:18
What you're asking about is precision, not accuracy. Your filesystem can say that a file's mtime is 2000000000.000001, but if your friendly neighborhood stratum 0 NTP clock says that it's actually 1500000000.000001 then you aren't very accurate even though you are precise to the microsecond.
– Mike S
Jan 31 '17 at 16:18
Careful: the ext4 on-disk format stores times in nanoseconds, and you can store times with that precision using utimes(), but the clock source the kernel uses to set atime/mtime/ctime is not that precise--e.g. ext4 uses current_time(), which uses current_kernel_time(), which is HZ/second granularity. (Probably about a millisecond--depending on your distro you may be able to figure out the value of HZ from 'grep CONFIG_HZ /boot/config-*')
– Bruce Fields
Feb 12 '18 at 15:40
Careful: the ext4 on-disk format stores times in nanoseconds, and you can store times with that precision using utimes(), but the clock source the kernel uses to set atime/mtime/ctime is not that precise--e.g. ext4 uses current_time(), which uses current_kernel_time(), which is HZ/second granularity. (Probably about a millisecond--depending on your distro you may be able to figure out the value of HZ from 'grep CONFIG_HZ /boot/config-*')
– Bruce Fields
Feb 12 '18 at 15:40
add a comment |
3 Answers
3
active
oldest
votes
As far as I know, there is no place that this information is stored on. It is coded into the filesystem. However, you can manually make a list of filesystems and the corresponding precision. I would use a case statement to test the filesystem id against your list of filesystems. You can make the default 1 since there are very few examples where precision is less than 1 second.
Older versions of FAT and current versions of zip use 2-second timestamp precision from what I have read online. However, I suggest you fact-check that.
You can get the id of a file's filsystem with the following command.
stat -f --format="%t" $file
edited Jan 27 '12 at 21:05
Kevin
27k106299
answered May 6 '11 at 17:40
Stephen
28615
2
%iis unique per each file system, e.g. if you have twoext4partitions, each will have a different id.
– Mikel
May 6 '11 at 22:05
I edited my answer. Nice catch. I would vote you up if I could.
– Stephen
May 7 '11 at 3:45
Looks like this is the best available option - It would be interesting to know if there is an authoritative list like this online. I couldn't find one with a quick search.
– l0b0
May 9 '11 at 11:29
add a comment |
Normally you would be able to use statvfs or pathconf, but they don't seem to support any way to find out that piece of information.
Apparently such a feature is being discussed for a future POSIX standard
we will also file some aardvarks for a pathconf enhancement
to return the granularity of timestamps on a per path basis.
Unfortunately, I can't see any clean way to do that today, not even in an OS-specific manner.
Any approach that tries to build a list of file systems and whether it supports sub-second resolution is dangerous. For example, ext4 seems to support nanosecond resolution if the inodes are 256 bytes, but not if they are 128 bytes.
Compiling a comprehensive and accurate list would be hard, may require root access, and it might change tomorrow. Which sounds harder than just running stat a few times to me.
answered Apr 19 '11 at 7:26
Mikel
39k1099125
add a comment |
I just implemented a detection for a file database. I first set the timestamp of a file to 1234 millis, and then read it again and check if it is 1234 (at least ms precision) or 1000 (second precision). The things I learned so far were:
- XFS and EXT3: second precision
- EXT4: millisecond precision
- NTFS: 100ns precision (OK, got this from the docs...)
answered Dec 26 '18 at 14:08
Daniel
3381311
add a comment |
Your Answer
StackExchange.ready(function() {
var channelOptions = {
tags: "".split(" "),
id: "106"
};
initTagRenderer("".split(" "), "".split(" "), channelOptions);
StackExchange.using("externalEditor", function() {
// Have to fire editor after snippets, if snippets enabled
if (StackExchange.settings.snippets.snippetsEnabled) {
StackExchange.using("snippets", function() {
createEditor();
});
}
else {
createEditor();
}
});
function createEditor() {
StackExchange.prepareEditor({
heartbeatType: 'answer',
autoActivateHeartbeat: false,
convertImagesToLinks: false,
noModals: true,
showLowRepImageUploadWarning: true,
reputationToPostImages: null,
bindNavPrevention: true,
postfix: "",
imageUploader: {
brandingHtml: "Powered by u003ca class="icon-imgur-white" href="https://imgur.com/"u003eu003c/au003e",
contentPolicyHtml: "User contributions licensed under u003ca href="https://creativecommons.org/licenses/by-sa/3.0/"u003ecc by-sa 3.0 with attribution requiredu003c/au003e u003ca href="https://stackoverflow.com/legal/content-policy"u003e(content policy)u003c/au003e",
allowUrls: true
},
onDemand: true,
discardSelector: ".discard-answer"
,immediatelyShowMarkdownHelp:true
});
}
});
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
StackExchange.ready(
function () {
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2funix.stackexchange.com%2fquestions%2f11599%2fdetermine-file-system-timestamp-precision%23new-answer', 'question_page');
}
);
Post as a guest
Required, but never shown
3 Answers
3
active
oldest
votes
3 Answers
3
active
oldest
votes
active
oldest
votes
active
oldest
votes
As far as I know, there is no place that this information is stored on. It is coded into the filesystem. However, you can manually make a list of filesystems and the corresponding precision. I would use a case statement to test the filesystem id against your list of filesystems. You can make the default 1 since there are very few examples where precision is less than 1 second.
Older versions of FAT and current versions of zip use 2-second timestamp precision from what I have read online. However, I suggest you fact-check that.
You can get the id of a file's filsystem with the following command.
stat -f --format="%t" $file
edited Jan 27 '12 at 21:05
Kevin
27k106299
answered May 6 '11 at 17:40
Stephen
28615
2
%iis unique per each file system, e.g. if you have twoext4partitions, each will have a different id.
– Mikel
May 6 '11 at 22:05
I edited my answer. Nice catch. I would vote you up if I could.
– Stephen
May 7 '11 at 3:45
Looks like this is the best available option - It would be interesting to know if there is an authoritative list like this online. I couldn't find one with a quick search.
– l0b0
May 9 '11 at 11:29
add a comment |
As far as I know, there is no place that this information is stored on. It is coded into the filesystem. However, you can manually make a list of filesystems and the corresponding precision. I would use a case statement to test the filesystem id against your list of filesystems. You can make the default 1 since there are very few examples where precision is less than 1 second.
Older versions of FAT and current versions of zip use 2-second timestamp precision from what I have read online. However, I suggest you fact-check that.
You can get the id of a file's filsystem with the following command.
stat -f --format="%t" $file
edited Jan 27 '12 at 21:05
Kevin
27k106299
answered May 6 '11 at 17:40
Stephen
28615
2
%iis unique per each file system, e.g. if you have twoext4partitions, each will have a different id.
– Mikel
May 6 '11 at 22:05
I edited my answer. Nice catch. I would vote you up if I could.
– Stephen
May 7 '11 at 3:45
Looks like this is the best available option - It would be interesting to know if there is an authoritative list like this online. I couldn't find one with a quick search.
– l0b0
May 9 '11 at 11:29
add a comment |
As far as I know, there is no place that this information is stored on. It is coded into the filesystem. However, you can manually make a list of filesystems and the corresponding precision. I would use a case statement to test the filesystem id against your list of filesystems. You can make the default 1 since there are very few examples where precision is less than 1 second.
Older versions of FAT and current versions of zip use 2-second timestamp precision from what I have read online. However, I suggest you fact-check that.
You can get the id of a file's filsystem with the following command.
stat -f --format="%t" $file
edited Jan 27 '12 at 21:05
Kevin
27k106299
answered May 6 '11 at 17:40
Stephen
28615
As far as I know, there is no place that this information is stored on. It is coded into the filesystem. However, you can manually make a list of filesystems and the corresponding precision. I would use a case statement to test the filesystem id against your list of filesystems. You can make the default 1 since there are very few examples where precision is less than 1 second.
Older versions of FAT and current versions of zip use 2-second timestamp precision from what I have read online. However, I suggest you fact-check that.
You can get the id of a file's filsystem with the following command.
stat -f --format="%t" $file
edited Jan 27 '12 at 21:05
Kevin
27k106299
answered May 6 '11 at 17:40
Stephen
28615
edited Jan 27 '12 at 21:05
Kevin
27k106299
edited Jan 27 '12 at 21:05
Kevin
27k106299
edited Jan 27 '12 at 21:05
Kevin
27k106299
27k106299
answered May 6 '11 at 17:40
Stephen
28615
answered May 6 '11 at 17:40
Stephen
28615
answered May 6 '11 at 17:40
Stephen
28615
28615
2
%iis unique per each file system, e.g. if you have twoext4partitions, each will have a different id.
– Mikel
May 6 '11 at 22:05
I edited my answer. Nice catch. I would vote you up if I could.
– Stephen
May 7 '11 at 3:45
Looks like this is the best available option - It would be interesting to know if there is an authoritative list like this online. I couldn't find one with a quick search.
– l0b0
May 9 '11 at 11:29
add a comment |
2
%iis unique per each file system, e.g. if you have twoext4partitions, each will have a different id.
– Mikel
May 6 '11 at 22:05
I edited my answer. Nice catch. I would vote you up if I could.
– Stephen
May 7 '11 at 3:45
Looks like this is the best available option - It would be interesting to know if there is an authoritative list like this online. I couldn't find one with a quick search.
– l0b0
May 9 '11 at 11:29
2
2
%i is unique per each file system, e.g. if you have two ext4 partitions, each will have a different id.– Mikel
May 6 '11 at 22:05
%i is unique per each file system, e.g. if you have two ext4 partitions, each will have a different id.– Mikel
May 6 '11 at 22:05
I edited my answer. Nice catch. I would vote you up if I could.
– Stephen
May 7 '11 at 3:45
I edited my answer. Nice catch. I would vote you up if I could.
– Stephen
May 7 '11 at 3:45
Looks like this is the best available option - It would be interesting to know if there is an authoritative list like this online. I couldn't find one with a quick search.
– l0b0
May 9 '11 at 11:29
Looks like this is the best available option - It would be interesting to know if there is an authoritative list like this online. I couldn't find one with a quick search.
– l0b0
May 9 '11 at 11:29
add a comment |
Normally you would be able to use statvfs or pathconf, but they don't seem to support any way to find out that piece of information.
Apparently such a feature is being discussed for a future POSIX standard
we will also file some aardvarks for a pathconf enhancement
to return the granularity of timestamps on a per path basis.
Unfortunately, I can't see any clean way to do that today, not even in an OS-specific manner.
Any approach that tries to build a list of file systems and whether it supports sub-second resolution is dangerous. For example, ext4 seems to support nanosecond resolution if the inodes are 256 bytes, but not if they are 128 bytes.
Compiling a comprehensive and accurate list would be hard, may require root access, and it might change tomorrow. Which sounds harder than just running stat a few times to me.
answered Apr 19 '11 at 7:26
Mikel
39k1099125
add a comment |
Normally you would be able to use statvfs or pathconf, but they don't seem to support any way to find out that piece of information.
Apparently such a feature is being discussed for a future POSIX standard
we will also file some aardvarks for a pathconf enhancement
to return the granularity of timestamps on a per path basis.
Unfortunately, I can't see any clean way to do that today, not even in an OS-specific manner.
Any approach that tries to build a list of file systems and whether it supports sub-second resolution is dangerous. For example, ext4 seems to support nanosecond resolution if the inodes are 256 bytes, but not if they are 128 bytes.
Compiling a comprehensive and accurate list would be hard, may require root access, and it might change tomorrow. Which sounds harder than just running stat a few times to me.
answered Apr 19 '11 at 7:26
Mikel
39k1099125
add a comment |
Normally you would be able to use statvfs or pathconf, but they don't seem to support any way to find out that piece of information.
Apparently such a feature is being discussed for a future POSIX standard
we will also file some aardvarks for a pathconf enhancement
to return the granularity of timestamps on a per path basis.
Unfortunately, I can't see any clean way to do that today, not even in an OS-specific manner.
Any approach that tries to build a list of file systems and whether it supports sub-second resolution is dangerous. For example, ext4 seems to support nanosecond resolution if the inodes are 256 bytes, but not if they are 128 bytes.
Compiling a comprehensive and accurate list would be hard, may require root access, and it might change tomorrow. Which sounds harder than just running stat a few times to me.
answered Apr 19 '11 at 7:26
Mikel
39k1099125
Normally you would be able to use statvfs or pathconf, but they don't seem to support any way to find out that piece of information.
Apparently such a feature is being discussed for a future POSIX standard
we will also file some aardvarks for a pathconf enhancement
to return the granularity of timestamps on a per path basis.
Unfortunately, I can't see any clean way to do that today, not even in an OS-specific manner.
Any approach that tries to build a list of file systems and whether it supports sub-second resolution is dangerous. For example, ext4 seems to support nanosecond resolution if the inodes are 256 bytes, but not if they are 128 bytes.
Compiling a comprehensive and accurate list would be hard, may require root access, and it might change tomorrow. Which sounds harder than just running stat a few times to me.
answered Apr 19 '11 at 7:26
Mikel
39k1099125
edited May 6 '11 at 22:01
answered Apr 19 '11 at 7:26
Mikel
39k1099125
answered Apr 19 '11 at 7:26
Mikel
39k1099125
answered Apr 19 '11 at 7:26
Mikel
39k1099125
39k1099125
add a comment |
add a comment |
I just implemented a detection for a file database. I first set the timestamp of a file to 1234 millis, and then read it again and check if it is 1234 (at least ms precision) or 1000 (second precision). The things I learned so far were:
- XFS and EXT3: second precision
- EXT4: millisecond precision
- NTFS: 100ns precision (OK, got this from the docs...)
answered Dec 26 '18 at 14:08
Daniel
3381311
add a comment |
I just implemented a detection for a file database. I first set the timestamp of a file to 1234 millis, and then read it again and check if it is 1234 (at least ms precision) or 1000 (second precision). The things I learned so far were:
- XFS and EXT3: second precision
- EXT4: millisecond precision
- NTFS: 100ns precision (OK, got this from the docs...)
answered Dec 26 '18 at 14:08
Daniel
3381311
add a comment |
I just implemented a detection for a file database. I first set the timestamp of a file to 1234 millis, and then read it again and check if it is 1234 (at least ms precision) or 1000 (second precision). The things I learned so far were:
- XFS and EXT3: second precision
- EXT4: millisecond precision
- NTFS: 100ns precision (OK, got this from the docs...)
answered Dec 26 '18 at 14:08
Daniel
3381311
I just implemented a detection for a file database. I first set the timestamp of a file to 1234 millis, and then read it again and check if it is 1234 (at least ms precision) or 1000 (second precision). The things I learned so far were:
- XFS and EXT3: second precision
- EXT4: millisecond precision
- NTFS: 100ns precision (OK, got this from the docs...)
answered Dec 26 '18 at 14:08
Daniel
3381311
answered Dec 26 '18 at 14:08
Daniel
3381311
answered Dec 26 '18 at 14:08
Daniel
3381311
answered Dec 26 '18 at 14:08
Daniel
3381311
3381311
add a comment |
add a comment |
Thanks for contributing an answer to Unix & Linux Stack Exchange!
- Please be sure to answer the question. Provide details and share your research!
But avoid …
- Asking for help, clarification, or responding to other answers.
- Making statements based on opinion; back them up with references or personal experience.
To learn more, see our tips on writing great answers.
Some of your past answers have not been well-received, and you're in danger of being blocked from answering.
Please pay close attention to the following guidance:
- Please be sure to answer the question. Provide details and share your research!
But avoid …
- Asking for help, clarification, or responding to other answers.
- Making statements based on opinion; back them up with references or personal experience.
To learn more, see our tips on writing great answers.
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
StackExchange.ready(
function () {
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2funix.stackexchange.com%2fquestions%2f11599%2fdetermine-file-system-timestamp-precision%23new-answer', 'question_page');
}
);
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
3
What you're asking about is precision, not accuracy. Your filesystem can say that a file's mtime is 2000000000.000001, but if your friendly neighborhood stratum 0 NTP clock says that it's actually 1500000000.000001 then you aren't very accurate even though you are precise to the microsecond.
– Mike S
Jan 31 '17 at 16:18
Careful: the ext4 on-disk format stores times in nanoseconds, and you can store times with that precision using utimes(), but the clock source the kernel uses to set atime/mtime/ctime is not that precise--e.g. ext4 uses current_time(), which uses current_kernel_time(), which is HZ/second granularity. (Probably about a millisecond--depending on your distro you may be able to figure out the value of HZ from 'grep CONFIG_HZ /boot/config-*')
– Bruce Fields
Feb 12 '18 at 15:40