New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Unix.utimes with 0.0 #6289
Comments
Comment author: @damiendoligez This is what I propose:
|
Comment author: @Chris00 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 or utime : ?a: float -> ?m: float -> string -> unit with the time being the current time if the argument is not set (this requires to call Does this sound OK or is it too invasive? |
Comment author: @damiendoligez 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. |
Comment author: @Chris00 I am personally fine with your solution. I was more worried about others using this feature. |
Comment author: talex (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. |
Comment author: @xavierleroy Commit [trunk 0939a59]: use current time only if both arguments are exactly 0.0. Also, use utimes() in preference to utime(). |
Original bug ID: 6289
Reporter: @Chris00
Status: closed (set by @xavierleroy on 2017-02-16T14:18:29Z)
Resolution: fixed
Priority: normal
Severity: minor
Version: 4.01.0
Target version: 4.03.0+dev / +beta1
Fixed in version: 4.03.0+dev / +beta1
Category: standard library
Tags: junior_job
Monitored by: @gasche @hcarty
Bug description
The documentation says "A time of [0.0] is interpreted as the current time". However the implementation makes the test
or
which has two unfortunate consequences
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/
The text was updated successfully, but these errors were encountered: