Mantis Bug Tracker

View Issue Details Jump to Notes ] Issue History ] Print ]
IDProjectCategoryView StatusDate SubmittedLast Update
0006289OCamlstandard librarypublic2014-01-08 13:022017-02-16 15:18
ReporterChristophe Troestler 
Assigned To 
PlatformOSOS Version
Product Version4.01.0 
Target Version4.03.0+dev / +beta1Fixed in Version4.03.0+dev / +beta1 
Summary0006289: Unix.utimes with 0.0
DescriptionThe documentation says "A time of [0.0] is interpreted as the current time". However the implementation makes the test

    if (times.actime || times.modtime)


      if (tv[0].tv_sec || tv[1].tv_sec)

which has two unfortunate consequences
- If one time is 0.0 and the other one is not, 0.0 is not interpreted as the current time.
- If the time is 0.1 or any value in [0,1[ (thus not 0.0), it is interpreted as 0 because it is rounded down before the test.

Also, since the name is Unix.utimes and not Unix.utime, one should maybe prefer the utimes function (with its sub-second resolution) over the utime one when both are available.

Finally, one may also question the benefit of this convention. Maybe a function Unix.utimes_now would be a better replacement (Unix.utimes would thus have no exceptional behavior).
Additional InformationSee [^]
Attached Files

- Relationships

-  Notes
doligez (administrator)
2014-07-16 10:54

This is what I propose:

1. change the documentation to say that the current time is used for both iff both are 0.0.
2. change the implementation to use proper tests (== 0.0) instead of implicit cast to integer to bool.
Christophe Troestler (reporter)
2014-07-16 20:23

That would mitigate the problem indeed. However, since in doing so you change the semantics of the function and you do not speak of using utimes (or utimensat) as the default, another solution would be to deprecate utimes and add utime, say with the following signature:

utime : string -> (float * float) option -> unit


utime : ?a: float -> ?m: float -> string -> unit

with the time being the current time if the argument is not set (this requires to call `time` if only one of the two optional arguments is present but I think the semantics are less easily forgotten).

Does this sound OK or is it too invasive?
doligez (administrator)
2014-07-21 22:47
edited on: 2014-07-21 22:48

The problem with utimes (or more exotic functions like utimensat) is, as usual, portability. We try to rely only on POSIX-standard functions, and anything else needs to be auto-detected by the configure script.

If we make a new function, I'd rather go with your first one (an optional pair of floats) because it sticks with the interface of the underlying system call.

Also, I'm not convinced that the change in semantics is significant enough to warrant polluting the library with a deprecated function.

Christophe Troestler (reporter)
2014-07-26 22:31

I am personally fine with your solution. I was more worried about others using this feature.
talex (reporter)
2014-07-28 10:28

(author of the original blog post)

I'd also prefer the "(float * float) option" API to the optional arguments one, because I'd expect "utime ~a path" to set *only* the access time, not to set the mtime to the current time.

Just documenting that you can set the mtime to zero by setting the atime to something else would work for my use, though it's a bit ugly.
xleroy (administrator)
2015-12-06 17:37

Commit [trunk 0939a59]: use current time only if both arguments are exactly 0.0. Also, use utimes() in preference to utime().

- Issue History
Date Modified Username Field Change
2014-01-08 13:02 Christophe Troestler New Issue
2014-06-19 17:46 gasche Tag Attached: junior_job
2014-07-16 10:53 doligez Status new => confirmed
2014-07-16 10:53 doligez Target Version => 4.02.0+dev
2014-07-16 10:54 doligez Note Added: 0011835
2014-07-16 20:23 Christophe Troestler Note Added: 0011867
2014-07-21 22:47 doligez Note Added: 0011896
2014-07-21 22:47 doligez Target Version 4.02.0+dev => 4.02.1+dev
2014-07-21 22:48 doligez Note Edited: 0011896 View Revisions
2014-07-26 22:31 Christophe Troestler Note Added: 0011927
2014-07-28 10:28 talex Note Added: 0011930
2014-09-04 00:25 doligez Target Version 4.02.1+dev => undecided
2014-09-15 23:03 doligez Target Version undecided => 4.03.0+dev / +beta1
2015-12-06 17:37 xleroy Note Added: 0015060
2015-12-06 17:37 xleroy Status confirmed => resolved
2015-12-06 17:37 xleroy Resolution open => fixed
2015-12-06 17:37 xleroy Fixed in Version => 4.03.0+dev / +beta1
2017-02-16 15:18 xleroy Status resolved => closed
2017-02-23 16:43 doligez Category OCaml standard library => standard library

Copyright © 2000 - 2011 MantisBT Group
Powered by Mantis Bugtracker