-
Notifications
You must be signed in to change notification settings - Fork 528
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
[Xamarin.Android.Build.Tasks] CopyIfChanged use last "write" time #1968
[Xamarin.Android.Build.Tasks] CopyIfChanged use last "write" time #1968
Conversation
From the "obvious question is obvious" department: there are currently 7 uses of $ git grep File.GetLastAccessTimeUtc
src/Xamarin.Android.Build.Tasks/Tasks/CopyAndConvertResources.cs: var dstmodifiedDate = File.Exists (destfilename) ? File.GetLastAccessTimeUtc (destfilename) : DateTime.MinValue;
src/Xamarin.Android.Build.Tasks/Tasks/CopyAndConvertResources.cs: var dstmodifiedDate = File.Exists (destfilename) ? File.GetLastAccessTimeUtc (destfilename) : DateTime.MinValue;
src/Xamarin.Android.Build.Tasks/Tasks/CopyIfChanged.cs: var dstmodifiedDate = File.Exists (dest) ? File.GetLastAccessTimeUtc (dest) : srcmodifiedDate;
src/Xamarin.Android.Build.Tasks/Tests/Xamarin.Android.Build.Tests/BuildTest.cs: var lastTime = File.GetLastAccessTimeUtc (pdbToMdbPath);
src/Xamarin.Android.Build.Tasks/Tests/Xamarin.Android.Build.Tests/BuildTest.cs: File.GetLastAccessTimeUtc (pdbToMdbPath),
src/Xamarin.Android.Build.Tasks/Tests/Xamarin.Android.Build.Tests/BuildTest.cs: var lastTime = File.GetLastAccessTimeUtc (pdbToMdbPath);
src/Xamarin.Android.Build.Tasks/Tests/Xamarin.Android.Build.Tests/BuildTest.cs: File.GetLastAccessTimeUtc (pdbToMdbPath), Are these also problematic? I suspect that they are. |
The build errors are
looks like that is caused by
Hmm |
build |
Thats a serious number of typo's :( |
Arg conflicts... Fixing it. |
Fixes: dotnet#1962 Since 0adf1ae, I believe that resource changes on macOS have been flaky--sometimes working, sometimes not. They have been consistenly working on Windows, however... After writing the simplest test I could, I found that my machine on High Sierra could *sometimes* reproduce what our QA team was seeing. I had to add the `[Repeat]` NUnit attribute before I could get the failure to occur regularly. After debugging for quite some time, I noticed a mistake in the `CopyIfChanged` task. When comparing timestamps, it looks like it is using the last *access* time of the destination file instead of the last *write* time! I think this is likely a typo (unintended), since switching the call to `GetLastWriteTimeUtc` fixes the problem. Keeping the test is a good idea, because it seems a bit scary we didn't catch this yet...
I suspect that none of these intentional.
cb6816a
to
a2eac94
Compare
…1968) Fixes: #1962 Since 0adf1ae, I believe that resource changes on macOS have been flaky: sometimes working, sometimes not. They have been consistently working on Windows, however... After writing the simplest test I could, I found that my machine on High Sierra could *sometimes* reproduce what our QA team was seeing. I had to add the `[Repeat]` NUnit attribute before I could get the failure to occur regularly. After debugging for quite some time, I noticed a mistake in the `<CopyIfChanged/>` task: when comparing timestamps, it looks like it is using the last *access* time of the destination file instead of the last *write* time! I think this is likely a typo (unintended), since switching the call to `File.GetLastWriteTimeUtc()` fixes the problem. Keeping the test is a good idea, because it seems a bit scary we didn't catch this yet. With that discovery, we audited the rest of the codebase and found that we were using `File.GetLastAccessTimeUtc()` in several places. We have deemed these *all* to be accidental, and have replaced all occurrences of `File.GetLastAccessTimeUtc()` with `File.GetLastWriteTimeUtc()`.
Fixes: #1962
Since 0adf1ae, I believe that resource changes on macOS have been
flaky--sometimes working, sometimes not. They have been consistenly
working on Windows, however...
After writing the simplest test I could, I found that my machine on
High Sierra could sometimes reproduce what our QA team was seeing. I
had to add the
[Repeat]
NUnit attribute before I could get thefailure to occur regularly.
After debugging for quite some time, I noticed a mistake in the
CopyIfChanged
task. When comparing timestamps, it looks like it isusing the last access time of the destination file instead of the
last write time!
I think this is likely a typo (unintended), since switching the call
to
GetLastWriteTimeUtc
fixes the problem. Keeping the test is a goodidea, because it seems a bit scary we didn't catch this yet...