Fix "last accessed time" test failing on Windows

[aganea]

Summary

The tests in llvm/test/tools/llvm-objcopy/ELF/strip-preserve-atime.test fails on my machine, because the "last accessed time" is disabled in the OS by default since Windows XP. One needs to explicitly enable it for the feature to work. Otherwise the last access time is the last write time. Please see: https://superuser.com/questions/251263/the-last-access-date-is-not-changed-even-after-reading-the-file-on-windows-7

[amccarth]

I'm OK with this.

In an ideal world, it would be nice to ensure stripping preserves other the Windows creation timestamp while updating the last modification timestamp.

[aganea]

In D85669#2207688, @amccarth wrote:

I'm OK with this.

In an ideal world, it would be nice to ensure stripping preserves other the Windows creation timestamp while updating the last modification timestamp.

Thanks Adrian. The "last modification time" is preserved with llvm-strip -p, see llvm\test\tools\llvm-objcopy\ELF\strip-preserve-mtime.test which works fine (if that's what you meant).

[amccarth]

In D85669#2207983, @aganea wrote:

In D85669#2207688, @amccarth wrote:

I'm OK with this.

In an ideal world, it would be nice to ensure stripping preserves other the Windows creation timestamp while updating the last modification timestamp.

Thanks Adrian. The "last modification time" is preserved with llvm-strip -p, see llvm\test\tools\llvm-objcopy\ELF\strip-preserve-mtime.test which works fine (if that's what you meant).

It's confusing because tests are defined in terms of Posix terminology and concepts that don't translate directly to non-Posix systems like Windows. I guess that's fine for an ELF-specific option like --preserve-dates.

On Windows, without --preserve-dates, I would expect stripping in place to change the modification time but to preserve the file creation time. As far as I understand, Posix file systems don't have an equivalent of a Windows file creation time, so I doubt there's a test for that.

[aganea]

Commited as rGa680ea2c720751a3d724fd8282515924acb3bd32

[jhenderson]

FWIW, I've never had any problems on my Windows 10 machine. I just checked and the NtfsDisableLastAccessUpdate value on my machine is 0x80000003, which appears to be being treated as 1, as the value isn't updated when I open it for example. The documentation seems to suggest that that registry key is for when listing a directory's contents. fsutil behavior disablelastaccess states it's system managed, and enabled (i.e. last access times are enabled).

[jhenderson]

On further reading of the test and running on my machine, I'm not convinced that the full reasoning here is correct. touch -a does cause the access times on my machine to be updated, despite the registry setting, and the -p option preserves the value (and similarly without -p, the value gets changed when the file gets modified).

It's possible there is some system setting that's still involved, but I don't think it's the one you are saying it is. Could you dig further, please?

[aganea]

Hi @jhenderson!
I had NtfsDisableLastAccessUpdate = 0x80000002. With this, touch -a -t 199505050555.55 %t.1.o fails to update the "Last access time" to the requested date.
Setting it to 0x80000003 or 3 or 1 works (ie. touch succeeds)
I'm not sure exactly what is going on here, maybe NTFS sets the "Last access time" when the handle is closed, and thus overrides what touch does?
The bottom line is that other users could be in the same situation: the test will succeed or fail depending on the settings on their machine.

[jhenderson]

In D85669#2210806, @aganea wrote:

Hi @jhenderson!
I had NtfsDisableLastAccessUpdate = 0x80000002. With this, touch -a -t 199505050555.55 %t.1.o fails to update the "Last access time" to the requested date.
Setting it to 0x80000003 or 3 or 1 works (ie. touch succeeds)
I'm not sure exactly what is going on here, maybe NTFS sets the "Last access time" when the handle is closed, and thus overrides what touch does?
The bottom line is that other users could be in the same situation: the test will succeed or fail depending on the settings on their machine.

Okay, thanks. Looks like there's more values than are actually documented. Out of interest, what does fsutil behavior disablelastaccess say for you?

[aganea]

In D85669#2212552, @jhenderson wrote:

Okay, thanks. Looks like there's more values than are actually documented. Out of interest, what does fsutil behavior disablelastaccess say for you?

D:\llvm-project>fsutil behavior query disablelastaccess
DisableLastAccess = 2  (Géré par le système, désactivé)

Despite NtfsDisableLastAccessUpdate being 0x80000002 in the registry. This link has more information about the meaning of the value: https://dfir.ru/2018/12/08/the-last-access-updates-are-almost-back/

[jhenderson]

In D85669#2212888, @aganea wrote:

In D85669#2212552, @jhenderson wrote:

Okay, thanks. Looks like there's more values than are actually documented. Out of interest, what does fsutil behavior disablelastaccess say for you?

D:\llvm-project>fsutil behavior query disablelastaccess
DisableLastAccess = 2  (Géré par le système, désactivé)

Despite NtfsDisableLastAccessUpdate being 0x80000002 in the registry. This link has more information about the meaning of the value: https://dfir.ru/2018/12/08/the-last-access-updates-are-almost-back/

Weird - my machine has them disabled, yet the access times are updated, whilst yours are enabled, and the times are not updated?? Oh well, as you say, given that the system setting isn't something we can easily change, I think marking these as unsupported on Windows is probably the only thing we can do.

llvm/test/tools/llvm-objcopy/ELF/strip-preserve-atime.test

 # Note: ls -lu prints the accessed timestamp
 # NetBSD: noatime mounts currently inhibit 'touch -a' updates
-# UNSUPPORTED: system-netbsd
+# UNSUPPORTED: system-netbsd, system-windows
 
 # Preserve dates when stripping to an output file.
 # RUN: yaml2obj %s -o %t.1.o
 # RUN: touch -a -t 199505050555.55 %t.1.o
 # RUN: llvm-strip -p %t.1.o -o %t-preserved.1.o
 # RUN: ls -lu %t-preserved.1.o | FileCheck %s --check-prefix=CHECK-PRESERVE-ATIME
 # Check that the stripped output is in fact a valid object file.
 # RUN: llvm-readobj %t-preserved.1.o