Skip to content
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.

Sign up for GitHub

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

Jump to bottom

'Corrupted header in binary project.binary (not ECFG)' with exported PCK over 2.1 GB (32-bit signed int) #27168

Closed
ZZZZZcode opened this issue Mar 17, 2019 · 8 comments
Closed

'Corrupted header in binary project.binary (not ECFG)' with exported PCK over 2.1 GB (32-bit signed int) #27168

ZZZZZcode opened this issue Mar 17, 2019 · 8 comments
Assignees
@RandomShaper
Labels
archived bug high priority platform:windows topic:core
Milestone
4.0

Comments

@ZZZZZcode
Copy link

ZZZZZcode commented Mar 17, 2019 •
edited
Loading

Godot version:

3.1

OS/device including version:

Windows 7 x64

Issue description:

Cannot run exported project (there are 2 files in the folder *.EXE and *.PCK)
Get error:

Corrupted header in binary project.binary (not ECFG)
core/project_setting.cpp:484
Error: Could not load gme data at path '.'. Is the .pck file missing?

Looks like is something wrong with "project.binary" file in the PCK archive.
IMPORTANT THING:
If PCK file less that 2.1 GB all runs ok. If PCK file more than 2.1GB - i get error.

Steps to reproduce:
Just export project with PCK file size more than 2.1GB

Minimal reproduction project:

Sorry cannot provide this :(
@Galileo53
Copy link

Same problem with our project. It works if smaller than 2GB but fails if bigger than 2GB.
This is a showstopper because we cannot shrink the project below 2GB.

@ZZZZZcode
Copy link
Author

Yeah... I`m sure its a nasty bug. Maybe the solution is separate resources in several PCK files.
Then use:
ProjectSettings.load_resource_pack(....)

@bojidar-bg bojidar-bg added this to the 3.2 milestone Mar 19, 2019
@akien-mga akien-mga changed the title 'Corrupted header in binary project.binary (not ECFG)' error after project export 'Corrupted header in binary project.binary (not ECFG)' with exported PCK over 2.1 GB (32-bit) Mar 19, 2019
@akien-mga
Copy link
Member

CC @hpvb @RandomShaper

@bruvzg
Copy link
Member

bruvzg commented Mar 19, 2019

I can partially confirm this on macOS, Godot unable to store individual large files inside PCK:

@akien-mga akien-mga changed the title 'Corrupted header in binary project.binary (not ECFG)' with exported PCK over 2.1 GB (32-bit) 'Corrupted header in binary project.binary (not ECFG)' with exported PCK over 2.1 GB (32-bit signed into) Mar 19, 2019
@akien-mga akien-mga changed the title 'Corrupted header in binary project.binary (not ECFG)' with exported PCK over 2.1 GB (32-bit signed into) 'Corrupted header in binary project.binary (not ECFG)' with exported PCK over 2.1 GB (32-bit signed int) Mar 19, 2019
@bruvzg
Copy link
Member

bruvzg commented Mar 19, 2019

Also, Unix file access implementation uses long x = ftell(...) in multiple places.

AFAIK by default ftell / fseek are limited to 32-bits. Probably fseek64 / _fseeki64 (or whatever platform specific equivalents are) should be used instead in both Unix and Windows implementations.

@RandomShaper RandomShaper self-assigned this Mar 19, 2019
@RandomShaper RandomShaper mentioned this issue Mar 19, 2019
Closed
RandomShaper added a commit to RandomShaper/godot that referenced this issue May 2, 2019
@RandomShaper
Make all file access 64-bit
d51c41f 
This changes the types of a big number of variables.

General rules:
- Using `int64_t` in general. With 64-bit we no longer need to use unsigned type. That matches `Variant` better and avoids akward casts. Checks for negative numbers are performed where they don't make sense (seek, read/write buffer size).
- Previous point means no more `size_t` for file size/offsets.
- Not worrying about `FileAccess::get_64/store_64` working with unsigneds. I haven't found any place where conversion to unsigned will cause trouble and saves us from having to add `get/store_64_signed` or similar.
- Using `int32_t` integers for concepts not needing such a huge range, like pages, blocks, etc.

In addition:
- Improve usage of integer types in some related places; namely, `DirAccess`, core binds.
- The binding for `Directory::get_space_left()` tried to return the size in MiB, but the expression was missing parentheses, so the `1024 * 1024` is removed and it keeps working as usual, returning bytes.

Fixes godotengine#27168.
@akien-mga akien-mga mentioned this issue Nov 28, 2019
Closed
@RandomShaper RandomShaper modified the milestones: 3.2, 4.0 Jan 8, 2020
@RandomShaper
Copy link
Member

Moved this one to 4.0, since file access will keep being 32-bit in 3.x (and that's the cause of the problem).

@akien-mga
Copy link
Member

akien-mga commented Oct 1, 2020 •
edited
Loading

Closing as superseded by godotengine/godot-proposals#400 to keep everything in one place.

@dodgyville dodgyville mentioned this issue Dec 14, 2020
Closed
JOELwindows7 added a commit to Perkedel/HexagonEngine that referenced this issue Apr 20, 2021
@JOELwindows7
exceed 2 gb
94c83fa 
oh no. the PCK file exceed 2GB and when we run the export it doesn't work. we don't know how to reduce the import less than 2GB as this is the Godot bug in file system access.

- godotengine/godot#27168 pck more than 2.1 gb error
- godotengine/godot#44363 manually put an export template in root folder of this project
- https://godotengine.org/qa/75329/game-over-and-not-working-what-best-handle-this-godot-stable
- godotengine/godot-proposals#400 it seems that it will only fix in Godot 4.0
- https://docs.godotengine.org/en/stable/getting_started/workflow/export/exporting_pcks.html
- godotengine/godot#44363
- godotengine/godot#47254 akien is fixing, but this PR here is still WIP for now unfortunately

so now we added 2 export template: Windows and Linux, both 64 bit in the project root folder. simply run HexagonEngine.bat for Windows or HexagonEngine.sh for Linux respectively. those script will print "Hexagon Engine by Perkedel Technologies" then run respective export template.
@Patashu
Copy link

Patashu commented Jun 2, 2024

Adding a comment to this because this is the top google search result for this error message and there is a totally unrelated reason why it can happen!

How it happened: Apparently if you upload HTML5 builds to itch.io in multiple succession, and some people played on the intermediate build, their browser will cache some but not all of the HTML5 files, allowing them to attempt to play the game in an inconsistent state.

The solution: tell them to Ctrl+F5 lmao. No idea if there's an automateable solution besides 'don't do that'

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees

@RandomShaper RandomShaper

Labels
archived bug high priority platform:windows topic:core
Projects
None yet
Milestone
4.0
Development

Successfully merging a pull request may close this issue.

Make all file access 64-bit RandomShaper/godot
7 participants
@Patashu @akien-mga @bojidar-bg @bruvzg @RandomShaper @Galileo53 @ZZZZZcode