bleachbit
bleachbit copied to clipboard
bleachbit
"The specified module could not be found."
Launching from same folder (E:\X\Z Backup Settings_Tools\BleachBit), except I moved the folder to a new HDD and then renamed the new HDD back to letter to "E" (since last one was dying), I'm getting this error. All other portable apps in this folder launch fine.
I did NOT get this error before (launched from same location, portable version) and the app still launches despite the error. This makes no sense. All security settings are provided, even as admin launch the app still gives this launch error.
I saw it on Bleachbit forums that it's the space in names of folder causing this error (even though it didn't before). So I moved the portable folder to "E:\X\BleachBit-Portable" and launched it, there was no error. But now that means I'm moving it out of folder where all portable apps are, which is a bit annoying but I guess I'll have to live with this since the error was reported in 2019 and not really fixed.
While we're at it, extracting portable files into same folder and overwriting basically erased all previous settings (same version). That kinda makes the portable version pointless if it just wipes the settings in same folder.
Can you post a full traceback here? And try running with --debug if it gives nothing.
Heh, was confused about debug command, until I realized it's the console EXE that is run with it (sandbox doesn't make it clear).
Anyway, here's the log: bleachbit.log
Yes. It is also possible to paste in into message.
https://docs.github.com/en/get-started/writing-on-github/working-with-advanced-formatting/creating-and-highlighting-code-blocks#fenced-code-blocks
But I don't see the error here. Maybe post screenshot?
Here's the screenshot.
Do note, the app still works, after closing the error. It just refuses to see the name past "Z" for folder since there are spaces in between the name.
No idea. Maybe there is an error loading __file__ = E:\X\Z Backup Settings\_Tools\BleachBit\library.zip\bleachbit\SystemInformation.pyo. I would try https://www.dependencywalker.com/ but the error occurs after BleachBit started, so it is unlikely to help here.
It maybe be possible to set PYTHONVERBOSE=1 environment variable in console before running. Python should give more info about what is it doing, and the last lines may show the problem.
OK, so running the app as it is (despite the error) and cleaning things, I noticed one error showing up (which never did before) in red. Has shown up regularly after this issues started happening:
Error: winapp2_windows.windows_logs: Command to delete C:DumpStack.log Traceback (most recent call last): File "bleachbit\Worker.pyo", line 87, in execute File "bleachbit\Command.pyo", line 79, in execute File "bleachbit\FileUtilities.pyo", line 548, in getsize pywintypes.error: (123, 'FindFirstFileW', 'The filename, directory name, or volume label syntax is incorrect.')
Anyway, I'll just move Bleachbit folder since I can't be arsed with changing 50 other sandbox tools/utilities shortcuts in that folder, or ditch Sandbox version for installer. This is the only sandboxed app that has ever shown such issue, that "Z Backup" folder is filled with such tools, so this was new. Oh well.
Does that FindFirstFileW error happen only if BleachBit is in spaced folder?
I am not on Windows, but I would try to run BleachBit from source https://github.com/bleachbit/bleachbit#running-from-source and then try to replace the line https://github.com/bleachbit/bleachbit/blob/9f70f6191a554027549ca1487f578d41165aa603/bleachbit/FileUtilities.py#L548 with
finddata = False
Just to see if the error will gone.
If it is gone, then insert
print(extended_path(path))
there to see what it shows
@zero5zero6zero7 I could reproduce the RunDLL error message. Will continue tracing the issue.
@zero5zero6zero7 Seems like this build with the new Python, etc. solves the problem. You might want to check... build 2310
@zero5zero6zero7 Seems like this build with the new Python, etc. solves the problem. You might want to check... build 2310
Yeah, can confirm, the issue is solved in this build.
@rados good question
@zero5zero6zero7 thank you for confirming
Closing as resolved by #848
