|Anonymous | Login | Signup for a new account||2014-11-25 01:40 CET|
|Main | My View | View Issues | Change Log | Roadmap|
|View Issue Details|
|ID||Project||Category||View Status||Date Submitted||Last Update|
|0006289||OCaml||OCaml standard library||public||2014-01-08 13:02||2014-09-15 23:03|
|Target Version||4.03.0+dev||Fixed in Version|
|Summary||0006289: Unix.utimes with 0.0|
|Description||The 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.tv_sec || tv.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 Information||See http://roscidus.com/blog/blog/2014/01/07/ocaml-the-bugs-so-far/ [^]|
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)
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?
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)
|I am personally fine with your solution. I was more worried about others using this feature.|
(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.
|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|
|Copyright © 2000 - 2011 MantisBT Group|