File.SetLastWrite time fails on readonly files on Windows

[danmoseley]

            string path = Path.GetTempFileName();

            File.SetLastWriteTime(path, new DateTime(2000, 1, 1)); // succeeds
            File.SetAttributes(path, FileAttributes.ReadOnly); 
            File.SetLastWriteTime(path, new DateTime(2001, 1, 2)); // throws UnauthorizedAccessException

This is because SetLastWrite time tries to open a file handle with GENERIC_WRITE instead of only FILE_WRITE_ATTRIBUTES. This bug exists in .NET Framework as well and has been encountered by customers eg here and now reported in a DTS issue.

[ghost]

Tagging subscribers to this area: @dotnet/area-system-io
See info in area-owners.md if you want to be subscribed.

Issue Details

---

            string path = Path.GetTempFileName();

            File.SetLastWriteTime(path, new DateTime(2000, 1, 1)); // succeeds
            File.SetAttributes(path, FileAttributes.ReadOnly); 
            File.SetLastWriteTime(path, new DateTime(2001, 1, 2)); // throws UnauthorizedAccessException

This is because SetLastWrite time tries to open a file handle with GENERIC_WRITE instead of only FILE_WRITE_ATTRIBUTES. This bug exists in .NET Framework as well and has been encountered by customers eg here and now reported in a DTS issue.

Author:	danmoseley
Assignees:	-
Labels:	area-System.IO
Milestone:	-

[danmoseley]

I'll throw up a fix.

[stephentoub]

Just from a theoretical perspective, why is it incorrect to fail changing a read-only file? I get that UnauthorizedAccessException is a strange exception for that case, but isn't it a little strange to expect it to succeed?

[danmoseley]

1. Windows allows it just fine. It's precisely what this flag is for - we were just passing the wrong one.
2. Customers have asked for it, including a DTS customer today.
3. Linux allows it. Customer pointed out Windows is inconsistent due to the flag we're passing.

dan@danmoseL:~/tmp$ ll tmp
-r--r--r-- 1 dan dan 2 Jan  1  2020 tmp
dan@danmoseL:~/tmp$ chmod 444 tmp
dan@danmoseL:~/tmp$ touch -t 202101010101 tmp
dan@danmoseL:~/tmp$ ll tmp
-r--r--r-- 1 dan dan 2 Jan  1  2021 tmp

Note that my implementation of GNU touch on Windows does fail, I didn't look at sources, but under the debugger it doesn't seem to call CreateFile (or SetFileTime) after reading the attributes. It looks like it is choosing to bail when it sees the r/o flag.

[danmoseley]

@stephentoub thoughts on above?

[danmoseley]

Also it occurs to me that copying a readonly file changes the timestamp on it. You can also rename or move it, and set other attributes on it. It seems that readonly really means "cannot change the content".

[stephentoub]

Seems fine then.

[adamsitnik]

Customers have asked for it, including a DTS customer today.

@danmoseley Should we backport the fix? It was relatively low risk. Thank you for fixing it BTW.

[ericstj]

Reponed since customer is asking for this in 6.0.