mirror of
https://github.com/LisherSong/ps5-web-file-manager.git
synced 2026-10-06 08:00:23 +02:00
Server-side dispatch in src/extract.c:79 already routes .rar to
rar_extract(), but the upload + extract entry point was hard-coded
to accept only .zip via two layers:
- assets/index.html:71 <input accept=".zip,application/zip,...">
- assets/main.js:2340 if (!/\.zip$/i.test(file.name)) return;
v1.8.3 relaxes both to also accept .rar (and the two RAR MIME types),
plus a small i18n pass so the "uploading ZIP"/"ZIP body is large"
copy reads sensibly when the user picks a RAR. No backend, no engine,
no vendored changes.
What this enables today (v1.8.3):
- Upload a single-volume plaintext .rar in one click and have the
existing rar_extract() engine process it. Uploaded archive is
auto-deleted on success, same as .zip since v1.7.
Still NOT enabled (planned for v1.9.0):
- Multi-volume RAR (name.part01.rar + name.part02.rar + ...)
- Encrypted RAR (password-protected headers / entries)
Both still return extract_unsupported from the existing
third_party/unrar/dmc_unrar 1.7.0 (GPL-2.0) engine. v1.9.0 will
swap the vendor to opello/unrar 7.20.1 (UnRAR License) which
natively handles both.
Files (4):
assets/index.html: accept=".zip,.rar,application/zip,
application/x-zip-compressed,
application/vnd.rar,
application/x-rar-compressed"
assets/main.js: upload pre-check regex /.(zip|rar)$/i
assets/lang-en.js: "ZIP will be deleted" -> "archive will be deleted"
assets/lang-zh.js: upload ZIP / volume ZIP wording neutralized
CHANGELOG.md: v1.8.3 entry added above v1.8.2
84 host-side checks (70 ZIP + 14 RAR), 0 failures.