https://bugs.winehq.org/show_bug.cgi?id=36958
Martin Bukatovič martinb@marbu.eu changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |martinb@marbu.eu
--- Comment #7 from Martin Bukatovič martinb@marbu.eu --- (In reply to Damjan Jovanovic from comment #6)
It's just Linux that's been a disaster: https://blog.marbu.eu/posts/2019-02-17-btime/
If this was implemented via a new field in "struct stat", it would be easy to #ifdef. But it uses a new "struct statx" instead, which means that many functions in dlls/ntdll/unix/file.c which take "struct stat" parameters need to be changed just for Linux.
Additional problem mentioned in the blog post is that Linux kernel doesn't allow creation time field to be changed from user space (there is no syscall for that) while Windows allows that.
This means that even if the creation time is fetched from statx structure, the semantics will differ and use cases involving updating this field won't be even possible.
This is not a problem for operating systems from BSD family, because there the creation time field handling comes from design of FreeBSD's UFS2 file system, which assumed that the field can be changed to allow preservation of this information during backup restoration (eg. while extracting a tarball).