This can sometimes occur because the archive is being extracted at a directory level that is already pretty deep (c:\program files (x86)\bigfix enterprise…) and the additional directory levels in the archive itself exceed the Windows directory path limit.
Does your problem occur during extraction, or after extracting and during installation? In either case, you may have better luck creating a new top-level directory like c:\temp. 7-zip’s command-line driven “7za.exe” may help with that as Bigfix’s “extract” command doesn’t have much in the way of options.
I recall one case where the vendor’s media used directory depths right up to the maximum allowed level, and putting it under even a single directory level caused its installer to fail with “file not found” errors. If that’s the case, you could work around it with the SUBST command, to substitute a drive letter for a path. Ex.
SUBST B: C:\TEMP\EXTRACTION_PATH
then you can reference that path as B:\ as if it were a top-level drive.
And, by the way, if you’ve already created a directory path that you cannot remove because it exceeds the directory depth limit, I’ve found that Robocopy can remove it, via
robocopy c:\empty c:\long\bad\path /MIRE