NuGet pack "The DateTimeOffset specified cannot be converted into a Zip file timestamp" #3793

erdembayar · 2020-12-10T20:33:17Z

Bug

Regression: No

Last working version:
How are we preventing it in future:

Fix

Details: Running nuget pack .nuspec fails with the message
"The DateTimeOffset specified cannot be converted into a Zip file timestamp."
It happens with nuget 4.6.2 for a .dll file that has LastWriteTime 31/12/1979 23:00:00 +00:00

Reason for fail is ZipFile doesn't accept files with modified date before 1980/1/1 in constructor.

Also this fixes Timestamps of file of packed package is shifted by the timezone #7395
issue.

After fix

Input file for test:

Now this file modified in 1959 after packing looks like this:

Testing/Validation

Tests Added: Yes
Reason for not adding tests:
Validation:

… a Zip file timestamp"

test/NuGet.Core.Tests/NuGet.Packaging.Test/PackageBuilderTest.cs

nkolev92

Couple of suggestions.

src/NuGet.Core/NuGet.Packaging/PackageCreation/Authoring/PackageBuilder.cs

…ear 1980.

zkat

Just some minor suggested changes but this looks good!

src/NuGet.Core/NuGet.Packaging/PackageCreation/Authoring/PackageBuilder.cs

src/NuGet.Core/NuGet.Packaging/Strings.resx

src/NuGet.Core/NuGet.Packaging/PackageCreation/Authoring/PackageBuilder.cs

erdembayar · 2020-12-15T17:53:30Z

@NuGet/nuget-client

Can you someone refer to what is 'deterministic' flag here? Not sure if I need to take account of it too.

NuGet.Client/src/NuGet.Core/NuGet.Packaging/PackageCreation/Authoring/PackageBuilder.cs

Line 96 in e9722d6

_deterministic = false; // fix in https://github.com/NuGet/Home/issues/8601

NuGet.Client/src/NuGet.Core/NuGet.Packaging/PackageCreation/Authoring/PackageBuilder.cs

Lines 886 to 889 in e9722d6

    
           if (_deterministic) 
        
           { 
        
               entry.LastWriteTime = ZipFormatMinDate; 
        
           }

nkolev92 · 2020-12-15T20:04:49Z

Did you follow the link in NuGet/Home#8601?

It links the feature and why it was disabled.

…before 1/1/1980 00:00:00 UTC will be corrected, also any file created after 12/31/2107 23:59:58 UTC will be corrected.

erdembayar · 2020-12-16T19:45:44Z

Did you follow the link in NuGet/Home#8601?

It links the feature and why it was disabled.

Ok, just checked that one.

erdembayar · 2020-12-16T19:57:09Z

@nkolev92 @zivkan
Addressed review concerns. Please review again.

nkolev92 · 2020-12-16T20:30:19Z

src/NuGet.Core/NuGet.Packaging/PackageCreation/Authoring/PackageBuilder.cs

@@ -893,7 +911,35 @@ private ZipArchiveEntry CreateEntry(ZipArchive package, string entryName, Compre
        private ZipArchiveEntry CreatePackageFileEntry(ZipArchive package, string entryName, DateTimeOffset timeOffset, CompressionLevel compressionLevel)
        {
            var entry = package.CreateEntry(entryName, compressionLevel);
-            entry.LastWriteTime = timeOffset;
+
+            // Please note: ZipArchive stream reader randomly changes LastWriteTime by another 1 second off than what "entry.LastWriteTime" has, most likely bug on their side.


It's a limitation of the zip format, not a bug.

From https://en.wikipedia.org/wiki/ZIP_%28file_format%29 :

The FAT filesystem of DOS has a timestamp resolution of only two seconds; ZIP file records mimic this. As a result, the built-in timestamp resolution of files in a ZIP archive is only two seconds, though extra fields can be used to store more precise timestamps. The ZIP format has no notion of time zone, so timestamps are only meaningful if it is known what time zone they were created in.

I'd tweak the comment.

@nkolev92
Wow, how do you know it?
I wish I knew it before spend quite some time on seemingly non-trivial issue.

Ok. Addressed.

src/NuGet.Core/NuGet.Packaging/PackageCreation/Authoring/PackageBuilder.cs

erdembayar · 2020-12-16T21:50:27Z

@nkolev92
Please review again.

zivkan

Are there any tests that pack a file, then extract it, and make sure that the original and extracted files have the same timestamp (and that the CI agent is not on the UTC timezone)?

If not, I don't think we're done. I think we need to modify pack to make sure we're always setting UTC time, and modify the extraction code to make sure when setting the file's timestamp, that the API knows it's UTC, not local, time.

src/NuGet.Core/NuGet.Packaging/Strings.resx

src/NuGet.Core/NuGet.Packaging/PackageCreation/Authoring/PackageBuilder.cs

erdembayar · 2021-01-29T21:43:31Z

@erdembayar can you check if this PR will also fix NuGet/Home#7395?

@zivkan
I tested time zone scenarios in PST and Redmond timezones. Please review again.

erdembayar · 2021-01-29T21:43:47Z

@NuGet/client-team
Ready for review.

src/NuGet.Core/NuGet.Packaging/PackageCreation/Authoring/PackageBuilder.cs

nkolev92 · 2021-01-29T23:57:09Z

src/NuGet.Core/NuGet.Packaging/PackageCreation/Authoring/PackageBuilder.cs

+            }
+            else if (timeOffset > ZipFormatMaxDate)
+            {
+                if (!_zipFormatCorrected)


Why log only once?
We should log for all files that were adjusted.

Because of this comment to limit spamming.

The method WriteFiles iterates the files in the package and calls CreatePart for each. If you create a collection in this method, containing all the filenames with "out of range" dates in this method, then you can create a single message with all the affected files. As an example, see this pack validation rule

I agree with @zivkan

Limit spamming means omitting repetitive information.

Ok. I imitated your pattern but end result seems still same.

Currently dotnet.exe pack --no-build output looks like below:

File 'net5.0-windows/10218.dll' was last modified on '1/29/1956', which is out of range of what the zip format supports. Using '1/1/1980' instead. File 'netcoreapp3.1/10218.dll' was last modified on '1/29/1957', which is out of range of what the zip format supports. Using '1/1/1980' instead.

Can you elaborate more on removing repetitive information? Is below looks correct approach? But this one has some complexities. Instead of is we need to use are, so we need need to have another string resource specific for purpose. Also how about someone mix 1956 and 2200 files then what message to show (not sure if it's possible scenario)?

File 'net5.0-windows/10218.dll' was last modified on '1/29/1956', 'netcoreapp3.1/10218.dll' was last modified on '1/29/1957', which are out of range of what the zip format supports. Using '1/1/1980 instead'.

Other warnings had a block of text, followed by a list of shorter messages for each individual instance. So, you could think about changing the warning to something like:

The zip format supports a limited date range. The following files are outside the supported range: 'file1' changed from '1979-12-31' to '1980-01-01' 'file2' changed from '2108-01-01' to '2107-12-31'

This way we can avoid repeating the "out of range for what the zip format supports" text.

Also, if you were to do this in Visual Studio, you should see only a single entry in the error list, not one per file. I'm not sure if it reduces a list of warnings in a binlong.

Having said this, I was thinking about it over the weekend, and I'm feeling much less strongly about this. Consider a c# syntax error instead. If I have the same syntax error in multiple places in a single file, Roslyn is going to raise one warning per instance, not one warning per file or one warning per project. One difference is that in Visual Studio you can click the warning and go to the line of code, whereas NuGet doesn't. Even if NuGet had the capability to determine a filename and line number, for "go to error" in general, I'm not sure it makes sense for this specific warning. It probably makes sense here to have a single message with a list of affected files.

As mentioned in another comment, we should have an NU warning code, and a docs issue to document the NU code.

src/NuGet.Core/NuGet.Packaging/PackageExtraction/ZipArchiveExtensions.cs

erdembayar

Addressed comments.

erdembayar · 2021-01-30T00:20:26Z

src/NuGet.Core/NuGet.Packaging/PackageCreation/Authoring/PackageBuilder.cs

+            }
+            else if (timeOffset > ZipFormatMaxDate)
+            {
+                if (!_zipFormatCorrected)


Because of this comment to limit spamming.

src/NuGet.Core/NuGet.Packaging/PackageExtraction/ZipArchiveExtensions.cs

zivkan

The PR's initial comment wasn't updated to say "fixing: ..." for the additional issue that it fixes and should be closed when this PR is merged.

src/NuGet.Core/NuGet.Packaging/PackageExtraction/ZipArchiveExtensions.cs

src/NuGet.Core/NuGet.Packaging/PackageCreation/Authoring/PackageBuilder.cs

test/NuGet.Core.Tests/NuGet.Packaging.Test/PackageBuilderTest.cs

src/NuGet.Core/NuGet.Packaging/PackageCreation/Authoring/PackageBuilder.cs

src/NuGet.Core/NuGet.Packaging/Strings.resx

test/NuGet.Core.Tests/NuGet.Packaging.Test/PackageBuilderTest.cs

erdembayar

@zivkan
Thank you for your review. I addressed your comments. Please review again.

src/NuGet.Core/NuGet.Packaging/PackageCreation/Authoring/PackageBuilder.cs

test/NuGet.Core.Tests/NuGet.Packaging.Test/PackageBuilderTest.cs

src/NuGet.Core/NuGet.Packaging/PackageExtraction/ZipArchiveExtensions.cs

src/NuGet.Core/NuGet.Packaging/PackageCreation/Authoring/PackageBuilder.cs

erdembayar · 2021-02-01T22:36:36Z

src/NuGet.Core/NuGet.Packaging/PackageCreation/Authoring/PackageBuilder.cs

+            }
+            else if (timeOffset > ZipFormatMaxDate)
+            {
+                if (!_zipFormatCorrected)


Ok. I imitated your pattern but end result seems still same.

Currently dotnet.exe pack --no-build output looks like below:

File 'net5.0-windows/10218.dll' was last modified on '1/29/1956', which is out of range of what the zip format supports. Using '1/1/1980' instead. File 'netcoreapp3.1/10218.dll' was last modified on '1/29/1957', which is out of range of what the zip format supports. Using '1/1/1980' instead.

Can you elaborate more on removing repetitive information? Is below looks correct approach? But this one has some complexities. Instead of is we need to use are, so we need need to have another string resource specific for purpose. Also how about someone mix 1956 and 2200 files then what message to show (not sure if it's possible scenario)?

File 'net5.0-windows/10218.dll' was last modified on '1/29/1956', 'netcoreapp3.1/10218.dll' was last modified on '1/29/1957', which are out of range of what the zip format supports. Using '1/1/1980 instead'.

src/NuGet.Core/NuGet.Packaging/Strings.resx

test/NuGet.Core.Tests/NuGet.Packaging.Test/PackageBuilderTest.cs

zivkan

Great progress. Getting very close now.

src/NuGet.Core/NuGet.Packaging/PackageCreation/Authoring/PackageBuilder.cs

zivkan · 2021-02-01T23:55:24Z

src/NuGet.Core/NuGet.Packaging/PackageCreation/Authoring/PackageBuilder.cs

+            }
+            else
+            {
+                entry.LastWriteTime = timeOffset;


In my previous round of reviews, I asked to make sure timeOffset was in the UTC timezone before setting entry.LastWriteTime, but I don't see that it's checked or converted anywhere.

Just in case I added .UtcDateTime. But for actual physical files it's already in UTC timezone and it comes from below call stack.

This method calls our above method and passing lastWriteTime.

NuGet.Client/src/NuGet.Core/NuGet.Packaging/PackageCreation/Authoring/PackageBuilder.cs

Line 1126 in 49cc7eb

var entry = CreatePackageFileEntry(package, entryName, lastWriteTime, CompressionLevel.Optimal, warningMessage);

And this one calls above 1 and passing lastWriteTime.

NuGet.Client/src/NuGet.Core/NuGet.Packaging/PackageCreation/Authoring/PackageBuilder.cs

Lines 966 to 970 in 49cc7eb

CreatePart(

package,

file.Path,

stream,

lastWriteTime: _deterministic ? ZipFormatMinDate : file.LastWriteTime,

In non-deterministic mode lastWriteTime is file.LastWriteTime which actually reads UTC datetime here:

NuGet.Client/src/NuGet.Core/NuGet.Packaging/PackageCreation/Authoring/PhysicalPackageFile.cs

Lines 96 to 99 in 74781ba

else if (SourcePath != null)

{

_lastWriteTime = File.GetLastWriteTimeUtc(SourcePath);

return File.OpenRead(SourcePath);

But for actual physical files it's already in UTC timezone and it comes from below call stack.

Yes, but NuGet.Packaging is a package that customers can reference in their own projects, and by implementing their own IPackageFile that does not return UTC time, they could encounter problems. You've fixed it by using .UtcDateTime, but my point is that since NuGet is not only a tool, but also a package/SDK, we need to consider all the different possible usage.

zivkan · 2021-02-01T23:56:47Z

src/NuGet.Core/NuGet.Packaging/PackageCreation/Authoring/PackageBuilder.cs

@@ -957,6 +992,7 @@ private HashSet<string> WriteFiles(ZipArchive package, HashSet<string> filesWith
                }
            }

+            _logger?.Log(PackagingLogMessage.CreateMessage(warningMessage.ToString(), LogLevel.Information));


I didn't notice this before, but we should always have NU warning/error codes. So, you need to create a new one, and create a task in our docs repo to create docs for the new NU code.

Ok. I created NU5132 warning code. If it's wrong choice of warning code then please correct me.
Also I created follow up document issue.

zivkan · 2021-02-01T23:58:53Z

src/NuGet.Core/NuGet.Packaging/StringFormatter.cs

@@ -20,5 +20,17 @@ internal static class StringFormatter
                source,
                contentHash);
        }
+
+        internal static string ZipFileTimeStampModified(
+            string entry,


Suggested change

string entry,

string packagePath,

I'm taking your suggestion, but prefer filePath. Because packagePath might suggest actual package itself something like C:\Users\xxxxx\.nuget\packages\nuget.versioning, but here we're talking about just one of many files in it.

👍 as long as it's not "entry", because someone looking at this method without the context of knowing where it's being used may not undersatnd what "entry" means.

test/NuGet.Core.Tests/NuGet.Packaging.Test/PackageBuilderTest.cs

zivkan · 2021-02-02T00:42:04Z

test/NuGet.Core.Tests/NuGet.Packaging.Test/PackageBuilderTest.cs

-        [Theory, InlineData(false), InlineData(true)]
-        public void EmitRequireLicenseAcceptance_ShouldEmitElement(bool requireLicenseAcceptance)
+        [Fact]
+        public void PackageBuilder_CorrectTestWriteTimeAfterYear2107_Succeeds()


This test (after 2107) looks so similar to the previous test (before 1980) that it's quite difficult to tell them apart. It feels a lot like re-reviewing the same code.

Even though it will have slightly slower execution time, I think it would be better to have a single parameterized test (Theory) that takes fileTime (input) and packageTime (expected) as parameters, creates a nupkg with only a single file, and then asserts that single file's timestamp to the expected packageTime.

Yeah, they're very close. But they usually focus little bit different sides on edge cases, so I prefer to keep as it's.

Before 1980 2 files and after 1980 4 files are tested. More of upside of 1980.
But 2107 4 files and after 2107 2 files are tested. More of downside of 2107.

Of course we remove fine grained edge case testing then we can merge then into 1 unit test using Theory data.

test/NuGet.Core.Tests/NuGet.Packaging.Test/PackageBuilderTest.cs

erdembayar

@zivkan
Thank you for your follow up review.
I addressed your review comments and implemented block text warning which you mentioned.

With nuget.exe it's working as expected.

But dotnet.exe does own things when dealing with multiline warning text. It breaks each line into new warning. Now I'm wondering whether to keep as it's or revert back.

Here is what is memory:

Actual printed text, it breaks down each line into new warning.

erdembayar · 2021-02-02T02:40:52Z

src/NuGet.Core/NuGet.Packaging/PackageCreation/Authoring/PackageBuilder.cs

@@ -957,6 +992,7 @@ private HashSet<string> WriteFiles(ZipArchive package, HashSet<string> filesWith
                }
            }

+            _logger?.Log(PackagingLogMessage.CreateMessage(warningMessage.ToString(), LogLevel.Information));


Ok. I created NU5132 warning code. If it's wrong choice of warning code then please correct me.
Also I created follow up document issue.

src/NuGet.Core/NuGet.Packaging/PackageCreation/Authoring/PackageBuilder.cs

erdembayar · 2021-02-02T03:32:53Z

src/NuGet.Core/NuGet.Packaging/PackageCreation/Authoring/PackageBuilder.cs

+            }
+            else
+            {
+                entry.LastWriteTime = timeOffset;


Just in case I added .UtcDateTime. But for actual physical files it's already in UTC timezone and it comes from below call stack.

This method calls our above method and passing lastWriteTime.

NuGet.Client/src/NuGet.Core/NuGet.Packaging/PackageCreation/Authoring/PackageBuilder.cs

Line 1126 in 49cc7eb

var entry = CreatePackageFileEntry(package, entryName, lastWriteTime, CompressionLevel.Optimal, warningMessage);

And this one calls above 1 and passing lastWriteTime.

NuGet.Client/src/NuGet.Core/NuGet.Packaging/PackageCreation/Authoring/PackageBuilder.cs

Lines 966 to 970 in 49cc7eb

CreatePart(

package,

file.Path,

stream,

lastWriteTime: _deterministic ? ZipFormatMinDate : file.LastWriteTime,

In non-deterministic mode lastWriteTime is file.LastWriteTime which actually reads UTC datetime here:

NuGet.Client/src/NuGet.Core/NuGet.Packaging/PackageCreation/Authoring/PhysicalPackageFile.cs

Lines 96 to 99 in 74781ba

else if (SourcePath != null)

{

_lastWriteTime = File.GetLastWriteTimeUtc(SourcePath);

return File.OpenRead(SourcePath);

erdembayar · 2021-02-02T03:52:14Z

src/NuGet.Core/NuGet.Packaging/StringFormatter.cs

@@ -20,5 +20,17 @@ internal static class StringFormatter
                source,
                contentHash);
        }
+
+        internal static string ZipFileTimeStampModified(
+            string entry,


I'm taking your suggestion, but prefer filePath. Because packagePath might suggest actual package itself something like C:\Users\xxxxx\.nuget\packages\nuget.versioning, but here we're talking about just one of many files in it.

test/NuGet.Core.Tests/NuGet.Packaging.Test/PackageBuilderTest.cs

erdembayar · 2021-02-02T19:16:57Z

test/NuGet.Core.Tests/NuGet.Packaging.Test/PackageBuilderTest.cs

-        [Theory, InlineData(false), InlineData(true)]
-        public void EmitRequireLicenseAcceptance_ShouldEmitElement(bool requireLicenseAcceptance)
+        [Fact]
+        public void PackageBuilder_CorrectTestWriteTimeAfterYear2107_Succeeds()


Yeah, they're very close. But they usually focus little bit different sides on edge cases, so I prefer to keep as it's.

Before 1980 2 files and after 1980 4 files are tested. More of upside of 1980.
But 2107 4 files and after 2107 2 files are tested. More of downside of 2107.

Of course we remove fine grained edge case testing then we can merge then into 1 unit test using Theory data.

zivkan · 2021-02-02T20:52:51Z

src/NuGet.Core/NuGet.Packaging/PackageCreation/Authoring/PackageBuilder.cs

@@ -957,6 +997,13 @@ private HashSet<string> WriteFiles(ZipArchive package, HashSet<string> filesWith
                }
            }

+            var warningMessageString = warningMessage.ToString().Trim();


I think warningMessage.Length -= Environment.NewLine.Length will have better performance than .Trim(). I'm assuming the only reason to call .Trim() is to remove the trailing newline character(s).

Addressed. Good trick.

zivkan · 2021-02-02T21:00:39Z

src/NuGet.Core/NuGet.Packaging/PackageCreation/Authoring/PackageBuilder.cs

+            }
+            else
+            {
+                entry.LastWriteTime = timeOffset;


But for actual physical files it's already in UTC timezone and it comes from below call stack.

Yes, but NuGet.Packaging is a package that customers can reference in their own projects, and by implementing their own IPackageFile that does not return UTC time, they could encounter problems. You've fixed it by using .UtcDateTime, but my point is that since NuGet is not only a tool, but also a package/SDK, we need to consider all the different possible usage.

zivkan

All the potential product issues I can think of are fixed. It will be really great to fix these time zone issues 👍

zivkan · 2021-02-02T21:43:03Z

src/NuGet.Core/NuGet.Packaging/StringFormatter.cs

+        {
+            return string.Format(CultureInfo.CurrentCulture,
+                Strings.ZipFileTimeStampModifiedWarning,
+                listOfFileTimeStampModifiedMessages);


From the "Writing High Performance .NET Code" book, string.Format is much slower than string.Concat (for which the + operator is syntactic sugar.

Although this method isn't on a hot path, so isn't itself perf-critical, I think it's good to practise these things all the time, so that it's natural when you are working on perf-critical code.

return Strings.ZipFileTimeStampModifiedWarning + Environment.NewLine + listOfFileTimeStampModifiedMessages;, and remove {0} from the resource files.

Addressed. I bought the book. Currently couldn't make time to read it.

erdembayar · 2021-02-02T22:34:03Z

@nkolev92

Do you have any concern if I merge this PR? Please check my comment for block text warning output.

src/NuGet.Core/NuGet.Packaging/PackageCreation/Authoring/PackageBuilder.cs

erdembayar added 2 commits December 10, 2020 11:03

Fix NuGet pack "The DateTimeOffset specified cannot be converted into…

1e0437f

… a Zip file timestamp"

Add unit test for Zip file date before 1980 case

57bb207

erdembayar requested a review from a team as a code owner December 10, 2020 20:33

dtivel approved these changes Dec 10, 2020

View reviewed changes

test/NuGet.Core.Tests/NuGet.Packaging.Test/PackageBuilderTest.cs Outdated Show resolved Hide resolved

test/NuGet.Core.Tests/NuGet.Packaging.Test/PackageBuilderTest.cs Outdated Show resolved Hide resolved

nkolev92 reviewed Dec 11, 2020

View reviewed changes

src/NuGet.Core/NuGet.Packaging/PackageCreation/Authoring/PackageBuilder.cs Outdated Show resolved Hide resolved

erdembayar added 3 commits December 10, 2020 17:46

Address PR review comment by Damon and Nikolche

e45b889

Log that zip file modified dates are set to 1/4/1980 if it's before y…

d7bdb3c

…ear 1980.

Fix failing unit test

18e3bf0

erdembayar requested a review from JonDouglas December 14, 2020 18:15

zkat approved these changes Dec 14, 2020

View reviewed changes

src/NuGet.Core/NuGet.Packaging/PackageCreation/Authoring/PackageBuilder.cs Outdated Show resolved Hide resolved

src/NuGet.Core/NuGet.Packaging/Strings.resx Outdated Show resolved Hide resolved

zivkan reviewed Dec 14, 2020

View reviewed changes

src/NuGet.Core/NuGet.Packaging/PackageCreation/Authoring/PackageBuilder.cs Outdated Show resolved Hide resolved

erdembayar added 2 commits December 16, 2020 11:23

Make modified datetime passed to ZipArchive UTC so any file modified …

3f11fc4

…before 1/1/1980 00:00:00 UTC will be corrected, also any file created after 12/31/2107 23:59:58 UTC will be corrected.

Fix typos.

5c9d833

erdembayar requested review from nkolev92 and zivkan December 16, 2020 19:56

nkolev92 reviewed Dec 16, 2020

View reviewed changes

Added Zip file 2 second precision limitation comment.

ede2569

erdembayar requested a review from nkolev92 December 16, 2020 20:57

zivkan reviewed Dec 17, 2020

View reviewed changes

src/NuGet.Core/NuGet.Packaging/Strings.resx Outdated Show resolved Hide resolved

src/NuGet.Core/NuGet.Packaging/PackageCreation/Authoring/PackageBuilder.cs Outdated Show resolved Hide resolved

erdembayar added this to the Sprint 181 - 2020.12.21 milestone Jan 4, 2021

erdembayar modified the milestones: Sprint 181 - 2020.12.21, Sprint 182 - 2021.01.11 Jan 11, 2021

erdembayar added 2 commits January 12, 2021 12:57

Merge branch 'dev' into dev-eryondon-CannotBeConverted2ZipfileTimestamp

d89fcfb

Address code review comments by Andy for deterministic packing.

b212126

erdembayar force-pushed the dev-eryondon-CannotBeConverted2ZipfileTimestamp branch from f14cac8 to b212126 Compare January 13, 2021 00:02

erdembayar added 2 commits January 29, 2021 13:22

Revert accidental changes.

dea0eef

Cleanup comments.

bd1c76a

nkolev92 reviewed Jan 29, 2021

View reviewed changes

Address Nikolche's code review.

d9e5479

erdembayar commented Jan 30, 2021

View reviewed changes

zivkan reviewed Jan 30, 2021

View reviewed changes

erdembayar added 6 commits February 1, 2021 11:10

Address PR comment by Andy.

f24aff3

Merge branch 'dev' into dev-eryondon-CannotBeConverted2ZipfileTimestamp

af38361

Address comment about string.Fomatting.

69161ae

Fix typo.

a7f53aa

Fix typo.

c5c3ebf

Address more comments for string resouces.

49cc7eb

erdembayar commented Feb 1, 2021

View reviewed changes

zivkan reviewed Feb 2, 2021

View reviewed changes

erdembayar mentioned this pull request Jun 1, 2024

Document NU5132 NuGet/Home#13496

Open

Address additional review comments.

5d812dc

erdembayar commented Feb 2, 2021

View reviewed changes

zivkan reviewed Feb 2, 2021

View reviewed changes

zivkan approved these changes Feb 2, 2021

View reviewed changes

Address string.Format with string.Concat(+) for better performance.

b7737cb

nkolev92 approved these changes Feb 3, 2021

View reviewed changes

src/NuGet.Core/NuGet.Packaging/PackageCreation/Authoring/PackageBuilder.cs Show resolved Hide resolved

erdembayar added 2 commits February 2, 2021 16:37

Address comment by Nikolche.

fa51fa0

Check if warningMessage has something before trimming new line.

9bad83e

erdembayar merged commit 0461335 into dev Feb 3, 2021

erdembayar deleted the dev-eryondon-CannotBeConverted2ZipfileTimestamp branch February 3, 2021 21:36

erdembayar mentioned this pull request Jul 26, 2021

NuGet Package Manager extracts files with incorrect timestamp NuGet/Home#11039

Closed

akoeplinger mentioned this pull request Jan 17, 2024

[NuGet.org Bug]: Package counter-signature uses incorrect time (time zone bug?) NuGet/NuGetGallery#9780

Closed

	CreatePart(
	package,
	file.Path,
	stream,
	lastWriteTime: _deterministic ? ZipFormatMinDate : file.LastWriteTime,

	else if (SourcePath != null)
	{
	_lastWriteTime = File.GetLastWriteTimeUtc(SourcePath);
	return File.OpenRead(SourcePath);

NuGet pack "The DateTimeOffset specified cannot be converted into a Zip file timestamp" #3793

NuGet pack "The DateTimeOffset specified cannot be converted into a Zip file timestamp" #3793

Conversation

erdembayar commented Dec 10, 2020 • edited Loading

Bug

Fix

After fix

Testing/Validation

nkolev92 left a comment

Choose a reason for hiding this comment

zkat left a comment

Choose a reason for hiding this comment

erdembayar commented Dec 15, 2020 • edited Loading

nkolev92 commented Dec 15, 2020

erdembayar commented Dec 16, 2020 • edited Loading

erdembayar commented Dec 16, 2020

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

erdembayar commented Dec 16, 2020

zivkan left a comment

Choose a reason for hiding this comment

erdembayar commented Jan 29, 2021

erdembayar commented Jan 29, 2021

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

erdembayar left a comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

zivkan left a comment

Choose a reason for hiding this comment

erdembayar left a comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

zivkan left a comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

erdembayar left a comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

zivkan Feb 2, 2021 • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

zivkan left a comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

erdembayar commented Feb 2, 2021

erdembayar commented Dec 10, 2020 •

edited

Loading

erdembayar commented Dec 15, 2020 •

edited

Loading

erdembayar commented Dec 16, 2020 •

edited

Loading

zivkan Feb 2, 2021 •

edited

Loading