mirror of
https://github.com/SabreTools/BinaryObjectScanner.git
synced 2026-02-04 05:35:49 +00:00
Unable to extract cab file - is not a directory or file, skipping #203
Reference in New Issue
Block a user
Delete Branch "%!s()"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
Originally created by @Feathered-Serpent on GitHub (Aug 19, 2025).
Heya,
noticed this on a German game "Simon the Sorcerer: Wer will schon Kontakt?"
(Filesize: 1.976.850.298 Bytes)
(Filesize: 419.364.014 Bytes)
With 7zip I can easily extract the cab files and then run the scan against the extracted files, resulting in a find:
content2\bin_engine.dll: ProtectDISC 9.5-9.11 [Build 0x16008 / 90120]Protection ID also detects it:
@mnadareski commented on GitHub (Aug 19, 2025):
The "not a directory or file" just means that it didn't start extracting the cabinet so it tried to scan a temp directory that didn't exist.
On the other side, there are some fixes that are going into a base library of mine that might make MS-CAB handling safer, assuming that it's an MS-CAB and not an IS-CAB. If the MS-CAB uses LZX compression, then extracting for scan is only supported in the 32-bit version because of library dependencies. Which is very likely what you're running into.
@Feathered-Serpent commented on GitHub (Aug 19, 2025):
using the win_x86-executables I don't get any message on content1.cab, same message on content2.cab:
how can I check what kind of cab files those are?
@mnadareski commented on GitHub (Aug 19, 2025):
You have 2 easy options:
MSCFthen it's an MS-CAB. If it starts withISc(, then it's an InstallShield CAB@Feathered-Serpent commented on GitHub (Aug 19, 2025):
Seems like both are MS-CAB files:
@mnadareski commented on GitHub (Aug 19, 2025):
Okay, then it might be one of the cabinet types that will benefit from when some of the dependent libraries are updated. Some of the incompatibilities were addressed in the latest rolling release. You can try that out if you want.
@Feathered-Serpent commented on GitHub (Aug 19, 2025):
x64 is working fine with the rolling release.
x86 got me no information about content1.cab and OoM on content2.cab:
@mnadareski commented on GitHub (Aug 19, 2025):
Good to know. I'll try to fix the out of memory error you're seeing there. Glad the rolling release mostly fixed things, though.
@mnadareski commented on GitHub (Sep 7, 2025):
A bunch of the internals have been finally updated. This shouldn't OOM anymore.
@mnadareski commented on GitHub (Sep 20, 2025):
Internals have further been refined, this definitely shouldn't happen anymore.