or Create a profile
13 Apr, 2017 02:53 PM
When I updated to version Octopus.3.11.16-x64 and today to Octopus.3.12.4-x64 indexes of the package repository were re-indexed. In the task log it runs a task after installing both versions. The task is called "Re-index built-in package repository".
When running I get a lot of warnings with the following message:
Error indexing package 'D:\Octopus\Packages<mypackagename>.20161221.1.0.nupkg'.
Central Directory corrupt.
System.IO.InvalidDataException: Central Directory corrupt. ---> System.IO.IOException: An attempt was made to move the file pointer before the beginning of the file.
at System.IO.__Error.WinIOError(Int32 errorCode, String maybeFullPath) at System.IO.FileStream.SeekCore(Int64 offset, SeekOrigin origin) at System.IO.FileStream.Seek(Int64 offset, SeekOrigin origin) at System.IO.Compression.ZipArchive.ReadEndOfCentralDirectory() --- End of inner exception stack trace --- at System.IO.Compression.ZipArchive.ReadEndOfCentralDirectory() at System.IO.Compression.ZipArchive.Init(Stream stream, ZipArchiveMode mode, Boolean leaveOpen) at Octopus.Core.Packages.Extraction.NupkgPackageExtractor.GetIndexPackageData(String packageFile) in Z:\buildAgent\workDir\eec88466c176b607\source\Octopus.Core\Packages\Extraction\NupkgPackageExtractor.cs:line 58 at Octopus.Server.Orchestration.BuiltInPackageRepository.SynchronizeBuiltInPackageRepositoryIndexTaskController.AddFileToIndex(String file, BuiltInPackageIndex repository, ICollection`1 packagesToAddToIndex) in Z:\buildAgent\workDir\eec88466c176b607\source\Octopus.Server\Orchestration\BuiltInPackageRepository\SynchronizeBuiltInPackageRepositoryIndexTaskController.cs:line 203 at Octopus.Server.Orchestration.BuiltInPackageRepository.SynchronizeBuiltInPackageRepositoryIndexTaskController.IndexPackages() in Z:\buildAgent\workDir\eec88466c176b607\source\Octopus.Server\Orchestration\BuiltInPackageRepository\SynchronizeBuiltInPackageRepositoryIndexTaskController.cs:line 159 Octopus.Server version 3.12.4 (3.12.4+Branch.master.Sha.e920c60cf410a29bf1f44038d49d4d9b551637d9)
When I look at the file it does exist on disk at the specified path, BUT the size is 0 bytes.
This task took about 12 minutes to complete.
1. Is this going to be a problem?
2. How should I deal with those 0 byte files (more then one file, didn't count them)?
3. How did those 0 byte files get there?
Thanks for helping out.
on 18 Apr, 2017 02:04 AM
Thanks for getting in touch!
These errors shouldn't cause any problems, looking at the code, we just log the exception and move on to the next package.
Are these 0 byte files new? The one you gave as an example looks to be from late 2016 (going by the package version)?
Not sure where these 0 byte files would've come from, how do you package / push your files to Octopus? Maybe there was an issue when pushing / uploading these packages.
I hope that helps!
Thank you and kind regards,
on 18 Apr, 2017 03:01 PM
We're deploying with Visual Studio Online to octopus. Can you make the error message less drastic
on 18 Apr, 2017 09:16 PM
I've raised this GitHub issue to have improve the error message.
Thank you and best regards,
on 19 Apr, 2017 07:14 AM
Thanks for improving that error message. Last question, can I delete the 0 byte files without consequences?
on 19 Apr, 2017 10:55 PM
Yes, you can remove the 0 byte files as they have somehow been corrupted and we won't be able to do anything with them, so they are just going to create noise in your logs.
Formatting help /
(switch to plain text)
(switch to Markdown)
You can attach files up to 10MB
If you don't have an account yet, we need to confirm you're human and not a machine trying to post spam.
A conversation has been started with the Octopus Deploy staff to resolve this discussion.
This discussion is private.
Only Octopus Deploy support staff and members of
can see and reply to it.
This discussion is public. Everyone can see and reply to it.
You can use Command ⌘ instead of Control ^ on Mac
Powered by Tender™.