mount: mark windows files archived and ignore a zero timestamp (#10559)

* mount: mark windows files archived and ignore a zero timestamp

Windows synthesises NORMAL when a file reports no attributes at all, which
is not the same as ARCHIVE and is what create_fileattr_test checks.

Utimens also wrote a zero timestamp through. Windows sends zero for a field
it is not setting, and storing it put 1970 in the atime overlay, which then
overrode the entry's real time — so a file created a moment ago reported an
access time of 1970 whenever the caller asked through an open handle.
Reading the path instead went down a different route and looked right,
which is why a probe of a fresh file showed nothing wrong.

* mount: match the file type by its mask, and only treat the epoch as unset

S_IFDIR is part of the multi-bit type field rather than a flag, so masking
against it alone also matched a symlink, which shares the bit. A regular
file is now identified by the type mask.

Rejecting every timestamp at or below zero also rejected a date genuinely
before 1970. Only the epoch itself is what Windows sends for a field it is
not setting, so that is all that is refused.

create_fileattr goes back on the known-failures list: the archive fix
works and the test simply moves on to ask for READONLY too, which needs
Chflags. Taking it off was premature.

* mount: drop the time overlays when an inode is released

atimeMap and dirMtimeMap are keyed by inode and were only ever trimmed by
a random eviction at capacity. Inodes are derived from the path, so a
delete and recreate hands the same number to a different file, which then
reported the previous file's access time — a file created a moment ago
answering with a time from long before it existed.

Cleared when Forget actually releases the inode, not on every decrement:
a partial forget still has users. Forget now reports that so callers
holding state keyed by the inode know when to drop it.

* ci: keep getfileinfo listed while its access time is unexplained

Two causes have been fixed and neither closed it, so the honest state is
listed-with-a-reason rather than removed in hope.

* mount: drop timestamp overlays while the inode table is locked

Forget released the inode under the table's lock but cleaned up the
atime and dir-mtime overlays after returning from it. Inode numbers are
derived from the path, so a lookup arriving in that window is handed the
same number back and can store a time that the cleanup then deletes.

Run the cleanup at the release point instead, as a callback under the
lock. The directory-cache purge stays deferred until after the unlock,
where it has to be.

Claude-Session: https://claude.ai/code/session_01EgY2QA3iiPtiu6ww3P2EBn

test/winfsp-conformance/known_failures.txt

@@ -58,11 +58,18 @@ exec_rename_dir_test
 
 # File information
 # ----------------
-# Windows attributes (hidden, system, readonly) and creation time are not
-# round-tripped: attrToStat leaves Flags unset and reports ctime as birthtime.
+# A regular file reports as archived now, but hidden, system and readonly are
+# still not round-tripped: create_fileattr gets past the archive check and then
+# asks for READONLY as well, which needs Chflags. Creation time is reported as
+# ctime because the raw protocol's Attr carries no field for it outside darwin.
 create_fileattr_test
-create_readonlydir_test
+# getfileinfo asserts a file created a moment ago has an access time within ten
+# seconds of now, and it does not. Two causes have been fixed and neither was
+# it: Utimens no longer stores a zero timestamp, and the in-memory overlays are
+# dropped when an inode is released so a recycled number cannot inherit an old
+# time. Still unexplained, so it stays listed rather than pretended about.
 getfileinfo_test
+create_readonlydir_test
 setfileinfo_test
 
 # Directory enumeration