Add microseconds specs for File.mtime, .atime and .ctime #386

AlexWayfer · 2017-03-06T21:40:18Z

Three attemps to avoid zero in these values with small sleep (if failed).

And some code refactoring.

AlexWayfer · 2017-03-06T21:55:53Z

What can I do with these fails?

On my computer:

$ ruby -v /home/alex/Projects/ruby/mspec/bin/mspec-run core/file
ruby 2.3.3p222 (2016-11-21 revision 56859) [x86_64-linux]
[\ | ==================100%================== | 00:00:00]      0F      0E

Finished in 0.340896 seconds

110 files, 667 examples, 1263 expectations, 0 failures, 0 errors, 0 tagged

eregon · 2017-03-06T22:47:58Z

The failures are from the Windows CI, because I guess Windows does not have micro-second resolution for file times. You can wrap the new specs in platform_is_not :windows do ... end.

eregon · 2017-03-06T22:49:26Z

core/file/atime_spec.rb

+      @atime = File.atime(@file)
+      break if @atime.usec > 0
+      sleep 0.1
+    end


Please move this directly in the concerned spec as other specs do not need this, and the sleep wastes time.

before :each is executed before each it block.

eregon · 2017-03-06T22:58:14Z

core/file/ctime_spec.rb

+      @ctime = File.ctime(@file)
+      break if @ctime.usec > 0
+      sleep 0.1
+    end


ctime will not change just by retrying, creating another file with touch(tmp("ctime")) would be more helpful.

eregon · 2017-03-06T22:59:40Z

core/file/atime_spec.rb

+    3.times do
+      @atime = File.atime(@file)
+      break if @atime.usec > 0
+      sleep 0.1


Sleep only a millisecond, it's more than enough to change microseconds.

AlexWayfer · 2017-03-07T07:18:53Z

@eregon Why I think that condition by OS is incorrect: this can be not OS-specific, but FS-specific — rubinius/rubinius#3502 (comment)

We don't have builds on OS X, do we? So… it's embarrassing situation.

eregon · 2017-03-07T10:09:40Z

@AlexWayfer Right, so both platforms should be excluded then, but please verify if you can.
Filtering by filesystem is just too complicated.
Maybe we should whitelist platforms since it seems not so often supported, like:
platform_is :linux do ... end

We had OS X builds on Travis, but they are super slow so I pragmatically removed them.
OS X and many other platforms are tested there: http://rubyci.org/

In any case it is becoming obvious that this behavior is platform-dependent.

AlexWayfer · 2017-03-07T14:36:50Z

@eregon

Right, so both platforms should be excluded then, but please verify if you can.

I checked: OS X failed :(

Filtering by filesystem is just too complicated.

Yes, you right. I found sys-filesystem gem, but it doesn't work good for FS recognition :(

And I'm worried about Linux running on file systems where there is no support for microseconds.

But OK, I will add "whitelist platforms" check.

Reference: jruby/jruby#4520 (comment) Three attemps to avoid zero in these values with small sleep (if failed). And some code refactoring.

headius

Looks good. Consider increasing number of loops to reduce likelihood we hit zero usec three times in a row (which is pretty unlikely, but this is also pretty cheap to do a few more times.)

headius · 2017-03-07T15:19:36Z

core/file/atime_spec.rb

@@ -15,6 +15,17 @@
    File.atime(@file).should be_kind_of(Time)
  end

+  platform_is :linux do
+    it "returns the last access time for the named file with microseconds" do
+      3.times do


The cost of doing this repeatedly is pretty low, so this might as well be 10 or 100. But I support the idea in general; this was my stumbling block as well when I started to think about a spec.

The alternative would be to create a temporary file and forcibly modify these times, but I don't know if that's even possible for atime.

Note also that some Linux systems disable atime (e.g. via mount params) for better filesystem speed. I don't know if that will ever affect specs, though.

There is already only 1/1000 chance per iteration to get 0 (assuming millisecond granularity), so I think it's fine.
The second iteration will be even more unlikely to get 0 as the work in between will not take exactly one second.

The cost of doing this repeatedly is pretty low, so this might as well be 10 or 100.

Increased to 100.

The alternative would be to create a temporary file and forcibly modify these times, but I don't know if that's even possible for atime.

That's possible for atime and mtime via FileUtils#touch.

This alternative was used.

Note also that some Linux systems disable atime (e.g. via mount params) for better filesystem speed. I don't know if that will ever affect specs, though.

This comment added to code, if you don't mind.

Oh, it's already merged… What can I do?

I think it's OK as it is (that's why I merged it), but if you want to change please feel free to open another Pull Request.

OK, thank you!

eregon

This look great, thank you for the new specs!

eregon · 2017-03-07T15:28:47Z

core/file/ctime_spec.rb

@@ -14,6 +14,21 @@
    File.ctime(@file).should be_kind_of(Time)
  end

+  platform_is :linux do
+    it "Returns the change time for the named file (the time at which directory information about the file was changed, not the file itself) with microseconds." do


Small typo, specs descriptions should start with a lowercase letter.

Copy-pasted from previous it :(

What can I do with some fixes if that PR was merged? New PR?

I fixed it along with a few other cases in c5de600

eregon · 2017-03-07T15:30:49Z

core/file/atime_spec.rb

@@ -15,6 +15,17 @@
    File.atime(@file).should be_kind_of(Time)
  end

+  platform_is :linux do
+    it "returns the last access time for the named file with microseconds" do
+      3.times do


There is already only 1/1000 chance per iteration to get 0 (assuming millisecond granularity), so I think it's fine.
The second iteration will be even more unlikely to get 0 as the work in between will not take exactly one second.

AlexWayfer force-pushed the file-a_c_mtime-microseconds branch from 351f3ed to 1321c46 Compare March 6, 2017 21:49

eregon requested changes Mar 6, 2017

View reviewed changes

eregon reviewed Mar 6, 2017

View reviewed changes

Add microseconds specs for File.mtime, .atime and .ctime

9aba5c7

Reference: jruby/jruby#4520 (comment) Three attemps to avoid zero in these values with small sleep (if failed). And some code refactoring.

AlexWayfer force-pushed the file-a_c_mtime-microseconds branch from 1321c46 to 9aba5c7 Compare March 7, 2017 14:38

headius approved these changes Mar 7, 2017

View reviewed changes

eregon approved these changes Mar 7, 2017

View reviewed changes

eregon merged commit 495d072 into ruby:master Mar 7, 2017

AlexWayfer mentioned this pull request Jun 25, 2017

File.mtime doesn't return milliseconds oneclick/rubyinstaller2#52

Closed

AlexWayfer mentioned this pull request Apr 28, 2021

File.mtime doesn't return milliseconds oracle/truffleruby#2337

Closed

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Add microseconds specs for File.mtime, .atime and .ctime #386

Add microseconds specs for File.mtime, .atime and .ctime #386

AlexWayfer commented Mar 6, 2017

AlexWayfer commented Mar 6, 2017

eregon commented Mar 6, 2017 •

edited

eregon Mar 6, 2017

eregon Mar 6, 2017

AlexWayfer Mar 7, 2017

eregon Mar 6, 2017 •

edited

AlexWayfer Mar 7, 2017

eregon Mar 6, 2017

AlexWayfer Mar 7, 2017

AlexWayfer commented Mar 7, 2017

eregon commented Mar 7, 2017

AlexWayfer commented Mar 7, 2017

headius left a comment

headius Mar 7, 2017

eregon Mar 7, 2017

AlexWayfer Mar 7, 2017

AlexWayfer Mar 7, 2017

eregon Mar 7, 2017

AlexWayfer Mar 7, 2017

eregon left a comment

eregon Mar 7, 2017

AlexWayfer Mar 7, 2017

eregon Mar 7, 2017

eregon Mar 7, 2017

Add microseconds specs for File.mtime, .atime and .ctime #386

Add microseconds specs for File.mtime, .atime and .ctime #386

Conversation

AlexWayfer commented Mar 6, 2017

AlexWayfer commented Mar 6, 2017

eregon commented Mar 6, 2017 • edited

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

eregon Mar 6, 2017 • edited

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

AlexWayfer commented Mar 7, 2017

eregon commented Mar 7, 2017

AlexWayfer commented Mar 7, 2017

headius left a comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

eregon left a comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

eregon commented Mar 6, 2017 •

edited

eregon Mar 6, 2017 •

edited