file access problem

[tomblo]

Hello,
I keep getting the following error while setup is trying to install a supporting dll-file on a Windows 98 machine:

Source file <filename> not found <...\\data\\OFFLIN~1\\IFATUD~1... >
Please check if file is there and if you can access it.

The file is there (in a ...\\data\\OFFLINE\\IFATUDB5TEBAEV2LATVE2LWSYIFTFT0 - folder) and it shouldn't be a problem to access it. The setup runs fine on other platforms. Also some builds have worked on the Windows 98 machine while other builds of the unchanged(!) setup run into this error.

I haven't been able to figure out why this happens and would really appreciate any hints on this.


Thanks

Thomas

[CandiceJones]

Hi Thomas!

My guess is, your web builds fail and uncompressed builds work (or vice versa). This is usually caused when your source paths are too long, causing you to exceed the 256 character MAX_PATH limit in built setups. Just try to use shorter source paths in your setup, and the problem will go away. You can use the subst command to create subst'ed drives with shorter paths if you are not comfortable/able to change your build tree.

[tomblo]

Hi Candice!
Thanks for the reply, but I'm only working with uncompressed builds here, I should have mentioned that before.
The setup is being installed on test machines with different platforms from a network share.

But I have been thinking in the same direction: The message looks like DOS folder names are used and since there are several folders in the build under ...\\uncomressed\\data\\OFFLINE that all start with "IFATUDB5TE..." maybe the setup gets confused.
Just that this doesn't really make sense for a Windows 98 machine to me...

Any other ideas?

[CandiceJones]

I don't think the setup would get confused. You are probably exceeding the maximum character limit for paths on Win98. This is the only explanation for this situation.

[tomblo]

No, I didn't think the setup would get confused either - that's why I didn't even mention that in my initial post.

But I just found out that Microsofts Virtual PC gets confused with long filenames on shared network drives - sometimes at least. So it's definitely a VPC problem after all.
Thanks for your help and sorry for posting to the wrong forum