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

Exporting skins with sub-folders adds 0-Byte files that break the .osk #27540

Closed
LittleLilyBun opened this issue Mar 8, 2024 · 2 comments · Fixed by #27586
Closed

Exporting skins with sub-folders adds 0-Byte files that break the .osk #27540

LittleLilyBun opened this issue Mar 8, 2024 · 2 comments · Fixed by #27586
Assignees
@bdach
Labels
area:skinning priority:0 Showstopper. Critical to the next release.

Comments

@LittleLilyBun
Copy link

Type

Game behaviour

Bug description

When exporting a skin that has sub-folders, the game adds 0-Byte files named after the sub-folders. These files prevent the .osk from being imported into stable or extracted, effectively "corrupting" the file.
This was discussed on Discord.

Example of "corrupted" .osk (renamed to .zip for uploading) Totally fully features skin [Real Skin with Real Features] (Unknown).zip

Screenshots or videos

No response

Version

2024.302.1-lazer

Logs

compressed-logs.zip
@Gabixel
Copy link
Contributor

Gabixel commented Mar 8, 2024 •
edited

Small additional note here: if a subfolder is empty, it will be deleted and the exported zip will only keep the 0-byte file.
Here's a screenshot example with a non-legacy skin (but it doesn't seem to depend on the skin "version"):
image

And unzipping (with 7zip) says that the paths don't exist for these "folders / blank files":
image

@peppy peppy added the priority:0 Showstopper. Critical to the next release. label Mar 12, 2024
@bdach bdach self-assigned this Mar 12, 2024
bdach added a commit to bdach/osu that referenced this issue Mar 12, 2024
@bdach
Fix exports containing zero byte files after import from specific ZIP…
83e47b3 
… archives

Closes ppy#27540.

As it turns out, some ZIP archivers (like 7zip) will decide to add fake
entries for directories, and some (like windows zipfolders) won't.
The "directory" entries aren't really properly supported using any
actual data or attributes, they're detected by sharpcompress basically
by heuristics:

    https://github.com/adamhathcock/sharpcompress/blob/ab5535eba365ec8fae58f92d53763ddf2dbf45af/src/SharpCompress/Common/Zip/Headers/ZipFileEntry.cs#L19-L31

When importing into realm we have thus far presumed that these directory
entries will not be a thing. Having them be a thing breaks multiple
things, like:

- When importing from ZIPs with separate directory entries, a separate
  `RealmFile` is created for a directory entry even though it doesn't
  represent a real file
- As a result, when re-exporting a model with files imported from such
  an archive, a zero-byte file would be created because to the database
  it looks like it was originally a zero-byte file.

If you want to have fun, google "zip empty directories". You'll see
a whole gamut of languages, libraries, and developers stepping on this
rake. Yet another episode of underspecced mistakes from decades ago
that were somebody's "good idea" but continue to wreak havoc forevermore
because now there are two competing conventions you can't just pick one.
@bdach bdach mentioned this issue Mar 12, 2024
Merged
@cdwcgt
Copy link
Contributor

cdwcgt commented Apr 6, 2024

#26454
This may also be the cause of this problem.

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

@bdach bdach

Labels
area:skinning priority:0 Showstopper. Critical to the next release.
Projects
None yet
Milestone
No milestone
Development

Successfully merging a pull request may close this issue.

Fix exports containing zero byte files after import from specific ZIP archives bdach/osu
6 participants
@peppy @bdach @frenzibyte @cdwcgt @Gabixel @LittleLilyBun