# Mac Specific Installation Issues

## Recommended Posts

Another idea: could this problem be caused by my BGII - SoA install not being on the first partition of my drive? Doesn't seem likely since the install works part-way, but I thought I'd ask....
The issue seems to be that WeiDU is not searching the CDn/data folders, but is instead looking for everything in ./data. Most of the game's data is contained inside of the main data folder, but area tilesets, WED files (these files define the layout of the area and how the engine should assemble the tiles), and some specialized animations are included in the CDn/data folders inside of compressed BIFFs. For the most part, normal WeiDU installations will never touch this data (there isn't much call to patch existing tilesets, WEDs, or animations), so it will never actually be required to search the CDn/data folders. For this fixpack, however, there is at least this one patch that updates an existing WED file (as mentioned, it's a trivial patch and not at all required), and it seems that WeiDU cannot find, or simply will not search the CDn/data folders.

While this issue could be exacerbated by having the Baldur's Gate II installation on a separate partition, as long as the paths in your Baldur.ini file are correct (if you can play the game with a full installation without having to swap CDs, they are) and CD2/data/AREA050A.BIF exists (and is greater than 0 bytes in size), it would be a bug in WeiDU, not your setup. Assuming we can eventually narrow down the behavior (i.e., if this only happens on separate partitions, or only if the ':' character is used as the path separator (changing this to mirror the PC separator would prevent the game from playing, but may allow WeiDU to install the mods correctly), or if it's simply broken), we can file a bug report and hope that Wes eventually gets the time to track it down and squash it.

For now, I'd suggest simply commenting out the AR0512.WED fix, and then installation should proceed as normal (I think this is the only patch that fixes a file contained inside of the CDn/data BIFFs). The AR0512.TIS update will work -- this action simply copies a file that is included with the fixpack to the override folder (the only way this could fail is if the AR0512.TIS file were somehow missing or in the wrong place, or if the override directory was missing or couldn't be written to).

Howdy devSin,

Thanks for the detailed reply, I appreciate you taking the time to help me understand how & why things are happening.

The issue seems to be that WeiDU is not searching the CDn/data folders, but is instead looking for everything in ./data.

As a workaround, could this be solved by having the script move everything from all the CDn folders to ./data, then having it update the baldur.ini to reflect the location change?

While this issue could be exacerbated by having the Baldur's Gate II installation on a separate partition, as long as the paths in your Baldur.ini file are correct (if you can play the game with a full installation without having to swap CDs, they are) and CD2/data/AREA050A.BIF exists (and is greater than 0 bytes in size), it would be a bug in WeiDU, not your setup.

NP there, my full install works fine w/o any CD swapping and the AREA050A.BIF is there and not 0 bytes.

For now, I'd suggest simply commenting out the AR0512.WED fix, and then installation should proceed as normal (I think this is the only patch that fixes a file contained inside of the CDn/data BIFFs). The AR0512.TIS update will work -- this action simply copies a file that is included with the fixpack to the override folder (the only way this could fail is if the AR0512.TIS file were somehow missing or in the wrong place, or if the override directory was missing or couldn't be written to).

Done & done. I commented out what you told me to, but did not comment out the COPY string you told me about earlier. Here is the Terminal output:

[dialog.tlk] created, 62191 string entries

SUCCESSFULLY INSTALLED [Optional, but cool]

SUCCESSFULLY INSTALLED [super Happy Fun Lucky Modder Pack]

SUCCESSFULLY INSTALLED [bG2 Fixpack - Game Text Update]

SUCCESSFULLY INSTALLED [bG2 Fixpack - Alpha 4]

Everything seems dandy. So now you just need me to begin a new game and play from there, or do you have specific things for me to look at?

Thanks!

As a workaround, could this be solved by having the script move everything from all the CDn folders to ./data, then having it update the baldur.ini to reflect the location change?
It could, but WeiDU doesn't have actions to move files (only copy). So you'd have to copy all 2GB of data files in the CDn/data folders, and then update the INI file.

If you want to maintain a single-data folder install, you can manually move the files from the CDn/data folders to the main data folder in the following order: CD3 -> CD4 -> CD2 -> CD5. Then, you can create a "movies" folder in the main Baldur's Gate II folder, move all the movie BIFFs (from the CDn/movies folders) to the new folder, and then delete the (now empty) CDn directories. Finally, just update Baldur.ini so that all paths are specified as CDn:=: (where n is a number 1-5). This will prevent these WeiDU errors, and also bypass any incorrect paths in the key file (like the Umar Hills snafu with the original Mac release of ToB). That said, this is not an acceptable substitute for actually having WeiDU work correctly.

So now you just need me to begin a new game and play from there, or do you have specific things for me to look at?
I'll let Cam get back with any specific areas he wants play-tested. The only thing I'm really concerned about is the AR0512 tileset change. You can check this by either going to the temple of Helm in the Bridge District, or by opening the debug console and entering: CLUAConsole:MoveToArea("AR0512") -- once there, just post the results (it will either crash the game, or load normally). If it crashes, remember to clear the contents of the "temp" and "tempsave" directories before launching the game again.

EDIT: for the AR0512 tileset, I'd actually want you to test it twice. For the first pass, make sure that 3D support is *disabled* and load the area. If it doesn't crash, just make sure the water in the two pools at the north end of the area appear blue (they should). Then, *enable* 3D support and repeat. If it loads, check the pools again and make sure the water isn't showing up as green.

If you could also watch for any text in-game that appears double-spaced (maybe look at some item descriptions and go through some dialogues), it'd be appreciated. I think the TRA is using DOS line-breaks, which will cause the strings to appear double-spaced in NearInfinity (and if the talk file is tra-ified by WeiDU), but I don't know if this affects the text in-game (I doubt, but it's best to check).

EDIT: that said, feel free to test whatever you wish or play normally. You can also check the "Outstanding bugs" on the forums here (it may have been moved to the Pending Fixes board) and look for any particular fix that catches your eye and that you'd like to test.

If you want to maintain a single-data folder install, you can ... <snip>

That said, this is not an acceptable substitute for actually having WeiDU work correctly.

Thanks for the how-to - I'll file that away (it may be useful for testing our stuff at BASG). And I completely agree with your last statement, but I'm also of the opinion that workarounds to forward testing are feasible as long as (1) they don't create more problems and (2) one keeps trying to solve the main problem simultaneously.

EDIT: for the AR0512 tileset, I'd actually want you to test it twice. For the first pass, make sure that 3D support is *disabled* and load the area. If it doesn't crash, just make sure the water in the two pools at the north end of the area appear blue (they should). Then, *enable* 3D support and repeat. If it loads, check the pools again and make sure the water isn't showing up as green.

Done:

--> NP in the 1st run (blue water, check).

--> 2nd run (3D animations & acceleration ON): No crashes, but water is GREEN.

If you could also watch for any text in-game that appears double-spaced (maybe look at some item descriptions and go through some dialogues), it'd be appreciated. I think the TRA is using DOS line-breaks, which will cause the strings to appear double-spaced in NearInfinity (and if the talk file is tra-ified by WeiDU), but I don't know if this affects the text in-game (I doubt, but it's best to check).

I'll keep an eye out for it.

...feel free to test whatever you wish or play normally. You can also check the "Outstanding bugs" on the forums here (it may have been moved to the Pending Fixes board) and look for any particular fix that catches your eye and that you'd like to test.

Will do.

EDIT:

BTW: thanks for opening up this new Mac-specific testing forum (it escaped me to do that before) - what was I thinking?

Thanks for the how-to - I'll file that away (it may be useful for testing our stuff at BASG). And I completely agree with your last statement, but I'm also of the opinion that workarounds to forward testing are feasible as long as (1) they don't create more problems and (2) one keeps trying to solve the main problem simultaneously.
What is the name of the Baldur's Gate II directory? If it isn't BGII - SoA, un-comment out the AR0512 WED patch and try to re-install (after changing the name of the folder to "BGII - SoA").

Done:

--> NP in the 1st run (blue water, check).

--> 2nd run (3D animations & acceleration ON): No crashes, but water is GREEN.

Hmm. This should be impossible if it's actually using the TIS file. Is AR0512.TIS in the override folder?
What is the name of the Baldur's Gate II directory? If it isn't BGII - SoA, un-comment out the AR0512 WED patch and try to re-install (after changing the name of the folder to "BGII - SoA").

I've always kept it the original name (BGII - SoA). When I tried to install the fixpack again on a clean BGII - SoA directory, the process failed with a parsing error. It wouldn't work until I commented out the AR0512 WED patch. The entire debug file content is as follows:

WeiDU v 176 Log

./Setup-bg2fixpack
[On this architecture, WeiDU does not auto-update.
[./Chitin.key] 128 BIFFs, 35201 resources
[dialog.tlk] 62170 string entries
Possible HD/CD Path: [1]
Possible HD/CD Path: [1]
Possible HD/CD Path: [1]
Possible HD/CD Path: [1]
Possible HD/CD Path: [1]
Possible HD/CD Path: [1]
Possible HD/CD Path: [1]
Possible HD/CD Path: [1]
Possible HD/CD Path: [1]
[dialog.tlk] claims to be writeable.
[dialog.tlk] claims to be a regular file.
WARNING: parsing log [WeiDU.log]: Sys_error("WeiDU.log: No such file or directory")

[BG2FIXPACK/SETUP-BG2FIXPACK.TP2] PARSE ERROR at line 1 column 824926-824926
Near Text:
syntax error

[BG2FIXPACK/SETUP-BG2FIXPACK.TP2]  ERROR at line 1 column 824926-824926
Near Text:
Parsing.Parse_error
ERROR: parsing [BG2FIXPACK/SETUP-BG2FIXPACK.TP2]: Parsing.Parse_error
ERROR: problem parsing TP file [BG2FIXPACK/SETUP-BG2FIXPACK.TP2]: Parsing.Parse_error

FATAL ERROR: Parsing.Parse_error

WeiDU Timings
TOTAL                                    0.760 s
unmarshal TLK                          0.480 s
unmarshal KEY                          0.230 s
parsing .tp2 files                     0.000 s
loading files                          0.000 s

Hmm. This should be impossible if it's actually using the TIS file. Is AR0512.TIS in the override folder?

Yeah, you were right about that. The .tis file was not present in the override directory (FYI: this is the BGII - SoA directory that was successfully installed into yesterday (not the one I wrote about in the first part of this post). So I manually copied the AR0512.tis file from the tis directory in the bg2fixpack folder into my override folder. Now the water in AR0512 is BLUE.

I've always kept it the original name (BGII - SoA). When I tried to install the fixpack again on a clean BGII - SoA directory, the process failed with a parsing error. It wouldn't work until I commented out the AR0512 WED patch.

[bG2FIXPACK/SETUP-BG2FIXPACK.TP2] PARSE ERROR at line 1 column 824926-824926

Near Text:

syntax error

The WED fix wouldn't (nor could it) cause this. Likely there's an error in the encoding or somesuch, resolved when you saved the Tp2. The obscene column number makes me think this is probably a line-break issue (line-breaks must be either DOS or, preferably, Unix).

So I manually copied the AR0512.tis file from the tis directory in the bg2fixpack folder into my override folder. Now the water in AR0512 is blue.
All that remains, then, is to test this in ToB, before officially declaring me a turd.

If you get the chance, the next time you uninstall a WeiDU mod, make sure to save a log file, and let me know if WeiDU reports finding something other than [1] when searching for paths. I looked at the WeiDU source, and couldn't see any provisions for searching for the paths on anything but Windows in load.ml (I didn't really investigate too closely so I probably missed something); if not, it's likely this never worked (or hasn't worked for awhile, at least).

Howdy devSin,

Here to report on BG2 FixPack Installation under "ToB" Full install.

It took me 3 attempts to get it to install.

One general note: the following scrolled across the Terminal window multiple times during all 3 attempts:

ERROR: BIFF [./movies/25Movies.bif] cannot be loaded: Unix.Unix_error(20, "stat", "./movies/25Movies.bif")

Attempt #1: ran Setup-bg2fixpack.command directly (no changes to .tp2)

--> Brief result from the terminal:

Copying and patching 1 file ...
Copying and patching 1 file ...
Copying and patching 1 file ...
Copying and patching 1 file ...
Copying and patching 1 file ...
Copying and patching 1 file ...
Copying and patching 6 files ...
ERROR: BIFF [./movies/25Movies.bif] cannot be loaded: Unix.Unix_error(20, "stat", "./movies/25Movies.bif")
Copying and patching 20 files ...
Copying and patching 18 files ...
ERROR: BIFF [./movies/25Movies.bif] cannot be loaded: Unix.Unix_error(20, "stat", "./movies/25Movies.bif")
Copying and patching 2 files ...
Copying and patching 1 file ...
ERROR: BIFF [./data/AREA050A.bif] cannot be loaded: Unix.Unix_error(20, "stat", "./data/AREA050A.bif")
Stopping installation because of error.

ERROR Installing [BG2 Fixpack - Alpha 4], rolling back to previous state
Will uninstall 2493 files for [BG2FIXPACK/SETUP-BG2FIXPACK.TP2] component 0.
Uninstalled    2493 files for [BG2FIXPACK/SETUP-BG2FIXPACK.TP2] component 0.
ERROR: Unix.Unix_error(20, "stat", "./data/AREA050A.bif")
PLEASE email the file SETUP-BG2FIXPACK.DEBUG to webmaster@camagna.net

Attempt #2: Saved .tp2 with Unix line endings. No other changes.

--> Result from the terminal were the same as Attempt #2

Attempt #3: Commented out "COPY_EXISTING ~AR0512.WED~ ~OVERRIDE~" section. Saved .tp2 with Unix line endings.

--> Brief result from the terminal:

[dialog.tlk] created, 74123 string entries

SUCCESSFULLY INSTALLED [Optional, but cool]

SUCCESSFULLY INSTALLED [Super Happy Fun Lucky Modder Pack]

SUCCESSFULLY INSTALLED [BG2 Fixpack - Game Text Update]

SUCCESSFULLY INSTALLED [BG2 Fixpack - Alpha 4]

--> NOTE: AR0512.tis did not get moved to Override folder

I will e-mail all 3 debug files to CamDawg for his reveiw.

If you get the chance, the next time you uninstall a WeiDU mod, make sure to save a log file, and let me know if WeiDU reports finding something other than [1] when searching for paths. I looked at the WeiDU source, and couldn't see any provisions for searching for the paths on anything but Windows in load.ml (I didn't really investigate too closely so I probably missed something); if not, it's likely this never worked (or hasn't worked for awhile, at least).

Did that. Path is still reported at [1], as I detailed in my previous posts. I'll mailed that debug file to CamDawg as well.

ERROR: BIFF [./movies/25Movies.bif] cannot be loaded: Unix.Unix_error(20, "stat", "./movies/25Movies.bif")
This is the same issue as previous. These won't work because WeiDU isn't looking in CD5/movies (instead, it's looking for ./movies). Since these are ACTION_IF blocks to prevent installation on non-ToB installs, this isn't really an error per se.

Attempt #2: Saved .tp2 with Unix line endings. No other changes.
This wouldn't normally have any effect; I posted the line-break blurb in response to the funky parse error you posted about (which absolutely could not have been related to the WED patch). The WED patch will always fail (for now), since WeiDU will only search in the main data folder (and corresponding movies folder, if one exists), and ignores the CDn/ folders entirely.

I keep hoping to get some super-concrete data before throwing this at Wes, but my general idea now is that it simply doesn't work at all.

NOTE: AR0512.tis did not get moved to Override folder
Unless you comment out the ACTION_IF () BEGIN and corresponding END actions, the AR0512.tis shouldn't install (Cam jumped the gun on making this Windows-only). If you did comment it out and it still doesn't install, then I'm likely missing something simple (I don't have a recent copy here, so I can't say for certain what the exact code should be). For now, just manually copy AR0512.tis to the override directory to test the green water bug.

Did that. Path is still reported at [1], as I detailed in my previous posts. I'll mailed that debug file to CamDawg as well.
Yeah. I copy my uber ini file during patching, so when uninstalling, it picks up the pre-filled CLUAConsole: items (so it will be something like [CLUAConsole:movies/25movies.bif]). I simply didn't think of this before asking to see if the behavior varied.

After looking at the DEBUG files, there's not really a lot I can add to this conversation. I've changed the tis file copy so it's no longer platform-dependent. All of the other errors are based of the ToB file checks (which look for saradush.mve in 25movies.bif) or the ar0512.wed patch (which looks for AREA050A.bif). Both of these detect and execute correctly on both my SoA and ToB test installs. 25movies.bif is in cd5/movies and area050a.bif is in cd2/data.

The failure of saradush.mve detection would cause some ToB fixes to not be applied. In the meantime I've substituted one of Melissan's creature files until we can sort this out. I've attached the DEBUG files if they'll help. The tp2 has also been converted to *nix linebreaks--I'm not sure why it wasn't using these from the get-go but it's fixed now.

I suspect this is a WeiDU issue, either due to bad parsing of baldur.ini or some file system issue. In Windows, WeiDU does get the paths correct after parsing baldur.ini:

[./baldur.ini] loaded, 3265 bytes
Possible HD/CD Path: [C:\games\bg2clean_tob_nobd\]
Possible HD/CD Path: [C:\games\bg2\CD1\]
Possible HD/CD Path: [C:\games\bg2\CD2\]
Possible HD/CD Path: [C:\games\bg2\CD2\]
Possible HD/CD Path: [C:\games\bg2\CD3\]
Possible HD/CD Path: [C:\games\bg2\CD4\]
Possible HD/CD Path: [C:\games\bg2\CD5\]

(HDD and CD folders are different root folders since I've got multiple installs going.) Compare to what you've both reported, where WeiDU reports this:

[./Baldur.ini] loaded, 1484 bytes
Possible HD/CD Path: [1]
Possible HD/CD Path: [1]
Possible HD/CD Path: [1]
Possible HD/CD Path: [1]
Possible HD/CD Path: [1]
Possible HD/CD Path: [1]
Possible HD/CD Path: [1]
Possible HD/CD Path: [1]
Possible HD/CD Path: [1]
Possible HD/CD Path: [1]
Possible HD/CD Path: [1]

I'm not sure if this is enough for Wes to work with, but it might be time to get him involved.

debugs.rar

From my brief review, it looked like the path search was hard-coded (for paths a la MY:\windows\path\to\whatever -- I couldn't see that the biff_path_separator value in arch* was ever used). Not that I looked too closely (or would even be able to tell if something else was going on)... Somebody can try changing the paths for the Mac version to their Windows counterpart (as I previously suggested), but I'm not sure even this would work.

I'd shoot a bug to Wes; because of my setup here, however, I'm not able to reproduce or investigate the issue further (at least, not without re-creating the CDn/ directories), so no bug from me.

Howdy devSin,

What follows is my report for Alpha 4 of the FixPack with a Tob installation (haven't tried Alpha 5 yet). By making the changes to the .tp2 you posted previously:

//ACTION_IF ("%WEIDU_ARCH%" STRING_COMPARE_CASE "x86" = 0) THEN BEGIN
Ã‚Â COPY ~bg2fixpack/tis/ar0512.tis~ ~override~
//END

and

/*
COPY_EXISTING ~AR0512.WED~ ~OVERRIDE~
INSERT_BYTES ~%wallGroupsOffset%~ 0x0a
WRITE_LONG ~%wallGroupsOffset%~ 0x00020001
WRITE_LONG ~%wallGroupsOffset%~ + 0x04 0x00040003
WRITE_SHORT ~%wallGroupsOffset%~ + 0x08 0x05
WRITE_BYTE 0x062b 0x06
WRITE_LONG 0x64 ~%wallGroupsOffset%~ + 0x0a
WRITE_LONG 0x7c ~%wallGroupsOffset%~ + 0x0a
WRITE_LONG 0x94 ~%wallGroupsOffset%~ + 0x0a
WRITE_SHORT 0x0626 0x06
FOR (index = 0x9c; index < 0xac; index = index + 0x04) BEGIN
Ã‚Â  WRITE_LONG ~%index%~ ~%offset%~ + 0x0a
END
BUT_ONLY_IF_IT_CHANGES
*/

I was able to get a complete install (with the expected ERROR: BIFF [./movies/25Movies.bif] cannot be loaded: Unix.Unix_error(20, "stat", "./movies/25Movies.bif" 'non-error errors' ). Good news is the ar0512.tis did also get copied over to the Override folder as you said it should...

... the bad news is the presence of this file causes a ToB crash with this error when I tried to execute CLUAConsole:MoveToArea("AR0512") :

An Assertion failed in ChDimm.cpp at line number 7997
Programmer says: BGII - SoA:cd2:data:AREA050A.bif: attempted to use compressed BIF from CD, check free hard <message ends here>

I replaced the AREA050A.bif in the cd2 data folder with a fresh copy from CD2 - no help. The only fix was to remove the ar0512.tis from the Override folder, then I was able to move to AR0512 (but water was green, of course).

EDIT: and I have 8+ GB free space on that drive, so that shouldn't be an issue either.

... I gotta ask, am I screwing things up somehow?

No. It's supposed to crash. So it looks to be Mac SoA-only (@Cam: it's up to you whether you want to do a Mac OS X && SoA && !ToB check, or just remove this component with a Mac OS X check to eliminate the possibility of having someone install ToB after installing the fix pack with SoA).

Here's a copy of WeiDU v180 for Mac OS X that you can use to see if this allows WeiDU to find AR0512.WED (as I said, it's not really finding the paths at runtime, but hopefully fakes it well enough to allow this to work for most people). This is my super-sekrit custom version, so you may notice some differences (if it doesn't actually break anything, just ignore it).

No. It's supposed to crash. So it looks to be Mac SoA-only (@Cam: it's up to you whether you want to do a Mac OS X && SoA && !ToB check, or just remove this component with a Mac OS X check to eliminate the possibility of having someone install ToB after installing the fix pack with SoA).

Hold the phone!!

I just did a successful install of Alpha v5 on a full ToB install (using your 'super-sedrit' v180). Only caveat was that I had to place a copy of AR050A.bif in the BGII - SoA/data/ folder (otherwise I got the "ERROR: BIFF [./data/AREA050A.bif] cannot be loaded: Unix.Unix_error(20, "stat", "./data/AREA050A.bif")" error).

Other items:

1) Was able to CLUA to AR0512 and water was BLUE using 3D accel.

2) No changes were made to the .tp2 .

3) Beginning of the .debug file looked like:

[./Chitin.key] loaded, 590565 bytes
[./Chitin.key] 182 BIFFs, 41794 resources
[dialog.tlk] 74123 string entries
Possible HD/CD Path: [300]
Possible HD/CD Path: [300]
Possible HD/CD Path: [300]
Possible HD/CD Path: [300]
Possible HD/CD Path: [300]
Possible HD/CD Path: [300]
Possible HD/CD Path: [300]
Possible HD/CD Path: [300]
Possible HD/CD Path: [300]
Possible HD/CD Path: [300]
Possible HD/CD Path: [300]
[dialog.tlk] claims to be writeable.
[dialog.tlk] claims to be a regular file.
[WeiDU.log] parsed
[BG2FIXPACK/SETUP-BG2FIXPACK.TP2] parsed
Using Language [English]
[English] has 2 top-level TRA files
[bg2fixpack/english/gtu.tra] parsed
[bg2fixpack/english/gtu.tra] has 12629 translation strings
[bg2fixpack/english/setup.tra] parsed
[bg2fixpack/english/setup.tra] has 37 translation strings

--> I guess this is what you meant by the v180 not really following directory paths?

Anyway, things are looking good!

Possible HD/CD Path: [300]

Possible HD/CD Path: [300]

Possible HD/CD Path: [300]

Possible HD/CD Path: [300]

Possible HD/CD Path: [300]

Possible HD/CD Path: [300]

Possible HD/CD Path: [300]

Possible HD/CD Path: [300]

Possible HD/CD Path: [300]

Possible HD/CD Path: [300]

Possible HD/CD Path: [300]

This should definitely not be occurring. Unless WeiDU finds "CDn" somewhere in your ini files, it should report nothing at all (i.e., no more numbers). How did you invoke WeiDU (i.e., were you really using WeiDU v180, or was it some other version)?

WeiDU isn't searching for directory paths. If you had CD5:=:path:to:CD5, WeiDU isn't suddenly going to start working. For all intents and purposes, WeiDU is really just sending CD1->CD5 to it's BIFF search, as long as the CDn text exists somewhere in the INI files. For instance, with WeiDU v180, a debug log should look something like

Possible HD/CD Path: [CD5]
Possible HD/CD Path: [CD5]
Possible HD/CD Path: [CD1]
Possible HD/CD Path: [CD1]
Possible HD/CD Path: [CD2]
Possible HD/CD Path: [CD2]
Possible HD/CD Path: [CD3]
Possible HD/CD Path: [CD3]
Possible HD/CD Path: [CD4]
Possible HD/CD Path: [CD4]
[dialog.tlk] claims to be writeable.
[dialog.tlk] claims to be a regular file.
[WeiDU.log] parsed
[FIXPACK.TP2] parsed
Using Language [English]
[English] has 1 top-level TRA files
[FIXPACK/ENGLISH/FIXPACK.TRA] parsed
[FIXPACK/ENGLISH/FIXPACK.TRA] has 74107 translation strings
BIFF may be in hard-drive CD-path [CD4/movies/25Movies.bif]
BIFF may be in hard-drive CD-path [CD4/movies/25Movies.bif]
BIFF may be in hard-drive CD-path [CD3/movies/25Movies.bif]
BIFF may be in hard-drive CD-path [CD3/movies/25Movies.bif]
BIFF may be in hard-drive CD-path [CD2/movies/25Movies.bif]
BIFF may be in hard-drive CD-path [CD2/movies/25Movies.bif]
BIFF may be in hard-drive CD-path [CD1/movies/25Movies.bif]
BIFF may be in hard-drive CD-path [CD1/movies/25Movies.bif]
BIFF may be in hard-drive CD-path [CD5/movies/25Movies.bif]
BIFF may be in hard-drive CD-path [CD5/movies/25Movies.bif]

If this isn't what you're experiencing, then we definitely have some breakage somewhere.