Project

General

Profile

Actions

Bug #7109

closed

File.utime doesn't set nanoseconds

Added by Anonymous about 12 years ago. Updated almost 12 years ago.

Status:
Rejected
Assignee:
-
Target version:
-
ruby -v:
ruby 1.9.3p194 (2012-04-20 revision 35410) [x86_64-linux]
Backport:
[ruby-core:47841]

Description

Hi,
I'm having a problem with File.utime on RHEL 5/CentOS 5. The File.utime method seems not to set nanoseconds properly, see the attached test case, that fails (the nanoseconds get rounded to thousand, so in fact I get microseconds). The test doesn't seem to fail on newer platforms with the same Ruby version, though (RHEL 6/CentOS 6, Fedora 17). Note, that when creating/modifying files, the nanoseconds get set and are returned properly, so it seems that they are supported by filesystem.

Sample failure:

  1. Failure:
    test_utime(TestUtime) [/builddir/build/BUILD/rubygem-sprockets-2.4.5/opt/rh/ruby193/root/usr/share/gems/gems/sprockets-2.4.5/file_utime_fail.rb:10]:
    Expected: 391199303
    Actual: 391199000

Any idea what might be wrong?
Thanks!


Files

file_utime_fail.rb (272 Bytes) file_utime_fail.rb Anonymous, 10/05/2012 03:47 PM

Updated by akr (Akira Tanaka) about 12 years ago

2012/10/5 bkabrda (Bohuslav Kabrda) :

I'm having a problem with File.utime on RHEL 5/CentOS 5. The File.utime method seems not to set nanoseconds properly, see the attached test case, that fails (the nanoseconds get rounded to thousand, so in fact I get microseconds). The test doesn't seem to fail on newer platforms with the same Ruby version, though (RHEL 6/CentOS 6, Fedora 17). Note, that when creating/modifying files, the nanoseconds get set and are returned properly, so it seems that they are supported by filesystem.

utimensat system call is required to set nanosecond filestamp.
It is available since Linux 2.6.22.
(glibc support is also required but I'm not sure the exact version.)

I guess RHEL 5/CentOS 5 is older than that.

Tanaka Akira

Updated by Anonymous about 12 years ago

----- Original Message -----

2012/10/5 bkabrda (Bohuslav Kabrda) :

I'm having a problem with File.utime on RHEL 5/CentOS 5. The
File.utime method seems not to set nanoseconds properly, see the
attached test case, that fails (the nanoseconds get rounded to
thousand, so in fact I get microseconds). The test doesn't seem to
fail on newer platforms with the same Ruby version, though (RHEL
6/CentOS 6, Fedora 17). Note, that when creating/modifying files,
the nanoseconds get set and are returned properly, so it seems
that they are supported by filesystem.

utimensat system call is required to set nanosecond filestamp.
It is available since Linux 2.6.22.
(glibc support is also required but I'm not sure the exact version.)

I guess RHEL 5/CentOS 5 is older than that.

Tanaka Akira

True, kernel version is 2.6.19. So is there another way to solve this or do I have to get along with microseconds?

Thanks.

--
Regards,
Bohuslav "Slavek" Kabrda.

Updated by akr (Akira Tanaka) about 12 years ago

2012/10/5 Bohuslav Kabrda :

True, kernel version is 2.6.19. So is there another way to solve this or do I have to get along with microseconds?

We can't set a timestamp without appropriate system call.

Tanaka Akira

Updated by kosaki (Motohiro KOSAKI) about 12 years ago

utimensat system call is required to set nanosecond filestamp.
It is available since Linux 2.6.22.
(glibc support is also required but I'm not sure the exact version.)

I guess RHEL 5/CentOS 5 is older than that.

True, kernel version is 2.6.19. So is there another way to solve this or do I have to get along with microseconds?

No another way. This is kernel limitation. In other word, you can't
compare gettimeofday() result and stat() result straightforwardly.

btw, even tough you use RHEL6, you can see this issue if you use some
older filesystems.
it depend on filesystem.

btw2, http://en.wikipedia.org/wiki/Ext4 says nanosecond timestamp is a
new feature of ext4.
I suspect your "RHEL5" mean ext3.

Updated by mame (Yusuke Endoh) almost 12 years ago

  • Status changed from Open to Rejected

It cannot be avoided because the limitation is due to OS. Closing.

--
Yusuke Endoh

Actions

Also available in: Atom PDF

Like0
Like0Like0Like0Like0Like0