[Bug 47349] New: TesModManager require SetFileInformationByHandle with FileBasicInfo to properly set file timestamps

https://bugs.winehq.org/show_bug.cgi?id=47349

Bug ID: 47349
           Summary: TesModManager require SetFileInformationByHandle with
                    FileBasicInfo to properly set file timestamps
           Product: Wine
           Version: 4.9
          Hardware: x86-64
                OS: Linux
            Status: UNCONFIRMED
          Severity: normal
          Priority: P2
         Component: kernel32
          Assignee: [e-mail]
          Reporter: [e-mail]
      Distribution: ---

Hi. 
The Application TesModManager 1.6.50(a .NET Mod Manager for Bethesda Games)
require SetFileInformationByHandle with FileBasicInfo to be able to sucessfully
set file timestamp. Setting the timestamp is required for mods load order on
some bethesda games as Tes4 Oblivion.

on the log:
0009:fixme:file:SetFileInformationByHandle 0xd0, 0, 0x34f358, 40

[Bug 47349] TesModManager require SetFileInformationByHandle with FileBasicInfo to properly set file timestamps

https://bugs.winehq.org/show_bug.cgi?id=47349

Lorenzo Ferrillo  changed:

What    |Removed                     |Added
----------------------------------------------------------------------------
                URL|                            |https://www.nexusmods.com/o
                   |                            |blivion/mods/41346?tab=desc
                   |                            |ription

[Bug 47349] TesModManager require SetFileInformationByHandle with FileBasicInfo to properly set file timestamps

https://bugs.winehq.org/show_bug.cgi?id=47349

--- Comment #1 from Lorenzo Ferrillo  ---
Created attachment 64825
  --> https://bugs.winehq.org/attachment.cgi?id=64825
testcase

Ok, I was looking a bit into this. 
There seems to be two problems:
First SetFileInformationByHandle should delegate the information setting to
NtSetInformationFile.

Now NtSetInformationFile has a limited capabilities for setting file
attributes, but that's not important for this bug.
What's important is when I try to set timestamps. Timestamps are setted (the
old timestamp differ from the new timestamp), but are setted to a different
value that the one I specified, while this testcase when running on the
testbot, seems to show that Windows return the exact setted value when querying
the timestamp.
Now this may be or may be not a serious problem. If the setted timestamp use a
monotonic function (so bigger is the timestamp passed to the function, bigger
is the timestamp setted), there should0nt be any problem, otherwise there may
be issues to programs that use file timestamps as a sort of ordering (for
example Bethesda Games for mods and DLCs load order)

Also seems that ChangeTime timestamp is not setted at all.

[Bug 47349] TesModManager require SetFileInformationByHandle with FileBasicInfo to properly set file timestamps

[WineHQ Bugzilla]

https://bugs.winehq.org/show_bug.cgi?id=47349

Lorenzo Ferrillo  changed:

What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|UNCONFIRMED                 |RESOLVED
      Fixed by SHA1|                            |fdf8d7176f59043999b34ff4fac
                   |                            |dcbee14a7d6aa
         Resolution|---                         |FIXED

--- Comment #2 from Lorenzo Ferrillo  ---
According to wine source, the bug should be fixed with wine 4.13.
The first part at last. (The second part remains a divergence between Wine and
Windows, but it should only become a problem if the timestamp conversion
doesn't respect function monotony, however a more specfic bug for that should
be made).

[Bug 47349] TesModManager require SetFileInformationByHandle with FileBasicInfo to properly set file timestamps

[WineHQ Bugzilla]

https://bugs.winehq.org/show_bug.cgi?id=47349

Alexandre Julliard  changed:

What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|RESOLVED                    |CLOSED

--- Comment #3 from Alexandre Julliard  ---
Closing bugs fixed in 4.20.