Open LittleJake opened 1 year ago
👋 This is a known issue -- I never thought it was a real problem considering the temp folder is well, temporary in nature.
Would fixing this help you in any fashion? I'll admit I don't know if the issue is on the libarchive side or if it's just because we're not decoding a folder name properly.
I think we might have to unzip with shift-jis charset?
If not mind, is it okay to use some sort of hash values in place of the exact zip name?
Does it cause an actual problem (like images not showing up) or is it just annoying?
Well, it will cause web title showing unexpected characters. Besides, it's not capable to fully backup to windows machine unless in compressed format or ignorance of the temp folder.
Web title should use whatever's stored in metadata - - I think the only place we show the true filenames is next to the resolution/size metadata in the reader.
Web title should use whatever's stored in metadata - - I think the only place we show the true filenames is next to the resolution/size metadata in the reader.
Yep.
Tagging as volunteers just in case someone cares enough to fix this - I don't think we should use hashes though, that sounds like more trouble than it's worth. (Need to handle internal folders and subfolders in archives, avoid collisions etc etc)
At the same time I'm not convinced we should try guessing charsets and converting on the fly, that's liable to break depending on what filesystem the server is running on -- There's a reason most FS code in the current codebase just uses the raw bytes without trying to do any conversion.
@Difegue
Another problem shows up with the encoding.
The place holder will not work as expected.
That's because it's a folder, as mentioned in the error message. There's no need to create a placeholder in those scenarios 😛
Please describe your suggestion, and the problem it'd solve.
When comic's filename contains japanese, folder name will contain invalid characters in the temp folder.
Additional context