[Bug 36958] New: Wine emulates file creation time instead of fetching it from the underlying filesystem
http://bugs.winehq.org/show_bug.cgi?id=36958 Bug ID: 36958 Summary: Wine emulates file creation time instead of fetching it from the underlying filesystem Product: Wine Version: 1.7.22 Hardware: x86 OS: Linux Status: UNCONFIRMED Severity: enhancement Priority: P5 Component: ntdll Assignee: wine-bugs(a)winehq.org Reporter: t.artem(a)mailcity.com Created attachment 49071 --> http://bugs.winehq.org/attachment.cgi?id=49071 Far2 showing file modification/creation/lass access times. In Linux at least ext4 supports file creation time field (crtime), but Wine doesn't use it. Instead it uses mtime. Please, implement crtime for filesystems which impelement this field. -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
http://bugs.winehq.org/show_bug.cgi?id=36958 Jonas Jelten <jonas.jelten(a)gmail.com> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |jonas.jelten(a)gmail.com -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
https://bugs.winehq.org/show_bug.cgi?id=36958 --- Comment #1 from Austin English <austinenglish(a)gmail.com> --- This is your friendly reminder that there has been no bug activity for over a year. Is this still an issue in current (1.7.51 or newer) wine? -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
https://bugs.winehq.org/show_bug.cgi?id=36958 --- Comment #2 from Artem S. Tashkinov <t.artem(a)mailcity.com> --- (In reply to Austin English from comment #1)
This is your friendly reminder that there has been no bug activity for over a year. Is this still an issue in current (1.7.51 or newer) wine?
Yep. -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
https://bugs.winehq.org/show_bug.cgi?id=36958 Ken Sharp <imwellcushtymelike(a)gmail.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Keywords| |download, source -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
https://bugs.winehq.org/show_bug.cgi?id=36958 --- Comment #3 from Artem S. Tashkinov <aros(a)gmx.com> --- statx() does that https://man7.org/linux/man-pages/man2/statx.2.html -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
https://bugs.winehq.org/show_bug.cgi?id=36958 --- Comment #4 from Artem S. Tashkinov <aros(a)gmx.com> --- This is still relevant. -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
https://bugs.winehq.org/show_bug.cgi?id=36958 --- Comment #5 from Artem S. Tashkinov <aros(a)gmx.com> --- Alexandre, it must be relatively easy to fix. -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
https://bugs.winehq.org/show_bug.cgi?id=36958 Damjan Jovanovic <damjan.jov(a)gmail.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Ever confirmed|0 |1 Status|UNCONFIRMED |NEW CC| |damjan.jov(a)gmail.com --- Comment #6 from Damjan Jovanovic <damjan.jov(a)gmail.com> --- On FreeBSD and OSX, Wine got support for creation time back in 2012: commit 5da1eaf2131f29264b734bdf4cde072115b0762f Author: Charles Davis <cdavis5x(a)gmail.com> Date: Thu Nov 29 21:50:46 2012 -0700 ntdll: Add support for BSD-style creation ("birth") time. 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. -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
https://bugs.winehq.org/show_bug.cgi?id=36958 Martin Bukatovič <martinb(a)marbu.eu> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |martinb(a)marbu.eu --- Comment #7 from Martin Bukatovič <martinb(a)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). -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
https://bugs.winehq.org/show_bug.cgi?id=36958 --- Comment #8 from Artem S. Tashkinov <aros(a)gmx.com> --- Ted Ts'o wrote: POSIX and Single Unix Specification also doesn't provide a way to allow userspace to set ctime (inode change time). That's because the definition of "change time" is defined to include the time to change anything about the inode metadata --- including the inode timestamps. Simply, the definition of "birth time" is about the time that the inode was "birthed", and that's not something that you can change. The problem is that DOS has a concept of "creation time", which seems to mean "the time that the abstract concept of the file was created". So if a file was created somewhere in a build farm in Redmond, Washington, that's the time that the file should have, according to Microsoft. So Windows allows the "creation time" to be set to any arbitrary file, since installers need to be able to set the "abstract creation time". You can debate whether "birth time" (which can't be set) or a "abstract creation time" (which can set to any arbitrary value), is "better" but that's why Linux doesn't support a way to set the "birth time". Whether you think we should bow to what Microsoft dictates probably depends on how much you believe Windows is a legacy operating system or not. ???? Personally, it's not something I really care about, and if someone really wants to add a Windows-compatible "Creation Time", my suggestion would be to define an extended attribute where this could be stored. We *could* allocate space in the on-disk inode to store this timestamp, but since I would estimate 99.9% of deployed Linux systems don't care about Windows compatibility, it's not a good use of resources. We could also add a mount option which changes the semantics of birth time, but that adds extra complexity, and again, I would estimate that 99.9% of Linux systems (where I include all of the Linux deployments in Cloud VM's) don't care about Windows compatibility in this way. Cheers, - Ted -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
participants (2)
-
wine-bugs＠winehq.org -
WineHQ Bugzilla