• EditorBugs

  • Unable to open project - invalid block type?

    영어

Suddenly today one of my spine files just stopped working as if it was corrupted?

Here is the log:

goat.spine
[error] Not a valid project file: /Users/brian/Documents/projects/kr-unity-monorepo/kr-core/.SpineRaw_nonremote/Characters/goat/goat.spine
at s.cHy.(:898)
at s.pbF.(:279)
at s.Usk.(:192)
at s.rSD.(:125)
at s.Usk.(:187)
at s.vtm.run(:91)
<events>
Cause: s.tRy: java.util.zip.ZipException: invalid block type
at s.Rsl.(:145)
at s.Rsl.(:158)
at s.Rsl.(:340)
at s.cHy.(:944)
at s.cHy.(:892) ...
Cause: [zip] invalid block type
at java.util.zip.InflaterInputStream.read(Unknown Source)
at s.Rsl.(:143) ...
OpenAL 1.1, Default audio device
ERROR: Unable to open project: /Users/brian/Documents/projects/kr-unity-monorepo/kr-core/.SpineRaw_nonremote/Characters/goat/goat.spine
[error] Not a valid project file: /Users/brian/Documents/projects/kr-unity-monorepo/kr-core/.SpineRaw_nonremote/Characters/goat/goat.spine
at s.cHy.(:898)
at s.ved.(:507)
at s.byx.(:118)
at s.wao.(:1062)
at s.byx.(:117)
at com.esotericsoftware.spine.editor.Editor.I(:131)
at s.Usk.(:266)
at s.Usk.I(:224)
at s.rSD.I(:138)
at s.SRE.run(:198)
<events>
Cause: s.tRy: java.util.zip.ZipException: invalid block type
at s.Rsl.(:145)
at s.Rsl.(:158)
at s.Rsl.(:340)
at s.cHy.(:944)
at s.cHy.(:892) ...
Cause: [zip] invalid block type
at java.util.zip.InflaterInputStream.read(Unknown Source)
at s.Rsl.(_:143) ...

Related Discussions
...

Nate

Do you have any idea what could cause this? This has never happened in the several years that I've used Spine.
Recently we moved from bitbucket > github and I'm wondering if that could be the cause... Although our other spine files seem fine.

    It could be the file wasn't written correctly. This could happen if the Spine process terminated or power was lost while writing the file. When a file is written, the data is sent through the OS and there are various settings for how that works. It is possible that the OS accepts the data but has not yet written it to the physical drive. Removing power to the computer at that time can result in the file not being written or being written partially. The same can happen at the drive level. Nearly all SSDs accept the data immediately, keeping it in RAM until it can be stored permanently. A good SSD should have enough capacitance that it can complete storing the data even if power is lost, but not all do.

    Data stored in RAM, whether in the OS or in the drive, can be corrupted by a cosmic ray:

    Studies by IBM in the 1990s suggest that computers typically experience about one cosmic-ray-induced error per 256 megabytes of RAM per month.

    Data in RAM can also be corrupted by failing RAM. If the corrupt data is written to a file, the file will have the bad data. ECC RAM reduces the chances of this being a problem to extremely unlikely. Unfortunately that isn't in use in most workstation computers, even though there is no good reason for that. It's so unlikely that a cosmic event corrupts data we all just pretty much ignore it.

    Another possibility is that the file was modified after it was written. This could be done by malicious software or by accidentally overwriting the file with other software. It could also be failing hardware, where the data was not written correctly or can't be read correctly. That means you could write a file but get back different data when you read it later.

    I doubt moving to GitHub would cause this problem. If you don't see it happening again, I would just chalk it up to leprechauns. 🍀