-
-
Notifications
You must be signed in to change notification settings - Fork 1.6k
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
Add nanosecond precision to File.utime
on Unix
#15335
Add nanosecond precision to File.utime
on Unix
#15335
Conversation
Co-authored-by: Kubo Takehiro <[email protected]>
|
I hope that unlike #9392, this won't drop support for macOS < 10.13, High Sierra |
I suppose it would, assuming What's your concern with MacOS < 10.13? It has been EOL since 2019 so I don't see much reason to keep up support. It might be possible to do something similar to bytecodealliance/rustix#275 to keep old versions supported, but I doubt the effort would be justified. |
The `utimensat` and `futimens` syscalls only appeared in macOS 10.14. To keep some backward compatibility, the x86_64 bindings are fixed to not declare them. We can however assume the syscalls to be present when compiling for aarch64. `Crystal::System::File.utime` now falls back to `utimes` when `futimens` isn't defined. Adds the missing `AT_FDCWD` constant to aarch64-android bindings. Fixes the DragonflyBSD binding.
I kept the legacy syscalls for macOS x86_64 builds to keep support with macOS < 10.14, but use the new ones for aarch64 targets that's only supported since macOS 11+ (hence always fine). I also fixed the aarch64-android and dragonflybsd bindings. |
File.utime
on Unix
@ysbaddaden I updated the OP to include a full description of the change that can be used in the commit message. Please update it if you see any need. I'll wait for your go to merge this. |
@straight-shoota Perfect! |
Bump the minimum version after crystal-lang/crystal#15335
@ysbaddaden Would it be possible to keep the legacy ones on aarch64 as well? I'm still using macOS 10.13 on my M1 machine. |
What? But the minimum macOS version for the oldest M1 machine (Apple macbook Air 2020) is macOS 11.x 😕 All aarch64-apple-darwin targets necessarily have these syscalls. Do not confuse 10.13 (high sierra) with 13 (ventura). |
I suppose we could consider making this configurable somehow, in order to opt-in to the modern API on x86_64-darwin as well. |
@ysbaddaden Ah, you're right of course. I'm using macOS 12 (Monterey), so that's not an issue, I guess. |
Reopens #9392 with fixes to the android and solaris bindings, and
#system_utime
has already been updated to support nanosecond precision when available.Crystal::System::File.utime
usesLibC.utimensat
when available, otherwise falls back toutimes
.The
utimensat
syscall is specified in POSIX.1-2008 and was introduced in the following OS releases:To keep some backward compatibility, the x86_64-darwin bindings do not
declare it. We can however assume the syscalls to be present when
compiling for aarch64-darwin.