-
-
Notifications
You must be signed in to change notification settings - Fork 79
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.
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
[Bug]: Blank pages when opening .cbz archives with very long filenames #241
Comments
Just want to clarify the Preflight Checklist and mention of bug #193 The issues were just similar but not the exact same match |
It seems to be an |
In the end it turns out that it is a problem with long paths in Windows (Equal or greater than 260 characters), the reason it only happens with compressed files is because the final path can be a little longer when extracted to the Tmp folder. Example, in this case the Tmp path has 40 character more:
I have decided that in the event that the path is equal or greater than 260 characters, the short path of the file will be generated (Windows 8.3 short filename), NTFS supports these short paths (If it has not been manually disabled), so it should solve this issue in most cases 884bccd Example of the 8.3 short filename, in this case has 19 characters less:
Build with fix: https://mega.nz/file/SGh1FCgC#rjRqBd1aKsLeuzKKGZ3OsJ5mYJ8PWqtdBVp6u8VtM5c |
Thanks so much for this |
I have one of your build after your fix for this issue. And if I manually extract files into folder and try to open just images, then I get blank pages. |
It seems to be the same error as #251 I have made these changes to fix it 549b54c Build: https://mega.nz/file/iX4XWbxS#OdWlWLY3-P0FV_wPAe8ypxwgEVrMiPUMPAq27dJJWg0 |
It seems that the Windows short path solution does not work in this case, probably because the HDD where the images are located does not have short path enabled. I've made some new changes to fix this 7b1bbdf, when a path of less than 260 characters cannot be generated, if Build: https://mega.nz/file/rbZEgbRI#rGbM2her1XlWFlQf9ZbAuJZSt8NOiOo359TQOMr8w-A |
Yeah it's work now.
Depends on what's under the hood, eventually, it probably would be better to find better way to handle that. I mean sometimes such folder with long names is vol (like in my link above) and copy 300-600 mb to tmp for each folder it's kinda costly, I guess. But it's just thinking out loud, because it's up to you of course. |
Copied files are handled the same way as files extracted from CBZ, CBR, etc. As long as the time/size set in the app settings are not exceeded for the
Copying is not done with all images at once, when reading only the first 5-10 adjacent images are rendered, and as the reading progresses the rest, also if you have interpolation activated, it is likely that the copying will not be done during the entire reading.
A possible better option would be to create a Blob object for these cases, which is what is used for |
I'm not familiar with electron\js\ts, so is there a reason why it can copy files with long path to tmp but can't display them without short path when path.length>260? |
This is because
I've been looking and |
Closed as fixed and available in v1.3.0 |
Preflight Checklist
OpenComic Version
1.2.0
Operating System
Windows 11 23H2 build 22631.3767
Steps to reproduce
Open or rename a comics folders with a filename of over 170 characters then convert it to .cbz
Expected Behavior
Comics archive should open normally
Actual Behavior
Bug is similar to #193 When I toggle devtools it shows net::ERR_FILE_NOT_FOUND for each pages.
This error only happens with .cbz archives but doesn't occur with folders when extracted with the exact same long filenames which is weird.
I tested multiple files and found out this error only starts with filenames with over 170 characters (I used an online character counter while testing)
Error message
net::ERR_FILE_NOT_FOUND
Additional Information
No response
Sample file
No response
The text was updated successfully, but these errors were encountered: