Import fails when trying to drag&drop .osz beatmaps with existing map in song list

[mmotkim]

Type

Game behaviour

Bug description

I have a bunch of .osz beatmap files, when I import them into osu!lazer by drag and dropping it keeps failing with a prompt on the top right of screen (no crashing).

I tried to drag & drop some individually but also didn't work.

The same files still works on stable (with some beatmaps existing as well) with the same drag and drop method.

Might be irrelevant but the beatmaps are downloaded using a tool from /nzbasic/batch-beatmap-downloader.

I noticed the files' name format are different from the ones downloaded straight from osu.ppy.sh which could be the case here:

• My file names were: [id].osz (e.g. 1207609.osz, 84458.osz, ...)
• Official file names are: [id] [artist] - [song name].osz (e.g. 765169 Komiya Mao - can you understand me.osz)

Screenshots or videos

No response

Version

2004.1009.1-lazer , 20241001 (stable)

Logs

1729968951.runtime.log

[peppy]

Dunno, need a video of what you're doing or something. It all looks to work okay from logs.

[mmotkim]

2024-10-27.20-21-12.mp4

compressed-logs.zip

Here's the video reproducing, along with logs exported using the export button in lazer in case last time I might have sent the wrong log file.

Also I realized when recording this is that osu!lazer shows import completed for 2 beatmaps the first time, though those beatmaps are the ones existing already. After that it's just failing. This also happened when I first encountered this bug.

[bdach]

Logs have a bunch of this inside:

2024-10-27 13:21:33 [verbose]: No beatmap files found in the beatmap archive (567163.osz).

Can you provide an example of one of the archives that does this so I can see whether the tool is doing stuff wrong, or if it's somehow lazer failing to read it?

[mmotkim]

I made a backup of that whole osz folder, here's the file in question:
567163.zip

[bdach]

Um...

First of all, what you've attached is a .zip with an .osz inside. Provided it is the .osz you are importing, it's a little off. Because of this:

$ hexdump -C 567163.osz | head -n 30
00000000  2d 2d 2d 2d 2d 2d 2d 2d  2d 2d 2d 2d 2d 2d 2d 2d  |----------------|
00000010  2d 2d 2d 2d 2d 2d 2d 2d  2d 2d 35 33 61 31 64 39  |----------53a1d9|
00000020  37 64 64 31 66 65 33 37  63 36 0d 0a 43 6f 6e 74  |7dd1fe37c6..Cont|
00000030  65 6e 74 2d 44 69 73 70  6f 73 69 74 69 6f 6e 3a  |ent-Disposition:|
00000040  20 66 6f 72 6d 2d 64 61  74 61 3b 20 6e 61 6d 65  | form-data; name|
00000050  3d 22 66 69 6c 65 22 3b  20 66 69 6c 65 6e 61 6d  |="file"; filenam|
00000060  65 3d 22 35 36 37 31 36  33 20 48 61 6e 61 73 61  |e="567163 Hanasa|
00000070  6b 61 20 59 75 69 28 43  56 2d 20 4d 2e 41 2e 4f  |ka Yui(CV- M.A.O|
00000080  29 20 2d 20 48 61 72 75  6d 61 63 68 69 20 43 6c  |) - Harumachi Cl|
00000090  6f 76 65 72 2e 6f 73 7a  22 0d 0a 43 6f 6e 74 65  |over.osz"..Conte|
000000a0  6e 74 2d 54 79 70 65 3a  20 61 70 70 6c 69 63 61  |nt-Type: applica|
000000b0  74 69 6f 6e 2f 6f 63 74  65 74 2d 73 74 72 65 61  |tion/octet-strea|
000000c0  6d 0d 0a 0d 0a 50 4b 03  04 14 00 00 00 08 00 7a  |m....PK........z|
000000d0  54 cb 4a 95 79 df 05 3a  05 00 00 e3 0a 00 00 40  |T.J.y..:.......@|
// rest of output stripped as irrelevant

Whatever program it is that produced this file, appears to have preserved the Content-Disposition header from the download request...? No idea why anyone would want this.

When this stuff is stripped from the archive (all bytes until the PK\x03\x04 ZIP signature), the file imports fine. From a brief code inspection, it appears that stable's ZIP import library (SharpZipLib) might have been a bit more robust against this, while SharpCompress presumably sees the garbage at the start and just bails.

@ppy/team-client should we be making these cases work, or is this fine to wontfix? I'm leaning towards the latter, but curious of other opinions.

[smoogipoo]

I think we should only put effort into supporting this if there many cases outside of the mentioned tool. Until such cases are found, it's not worth even considering.

[bdach]

Alright, I'll tentatively close this as wontfix / broken external tool then.