Opened 12 years ago

Closed 12 years ago

Last modified 20 months ago

#3984 closed defect (fixed)

WIN: ScummVM doesn't find files

Reported by: SF/mac_es Owned by: fingolfin
Priority: normal Component: Port: Win32
Keywords: Cc:



Whith the today's trunk scummVM doesn't find any files in WindowsXP

scummvm --version WARNING: FilesystemNode::openForReading: FilesystemNode does not exist! ScummVM 0.13.0svn (Sep 30 2008 09:12:29) Features compiled in: Vorbis FLAC MP3 zLib MPEG2 FluidSynth

I have had to revert the revision 34680 of common/file.cpp to make it again runnable.

Whith that revision it doesn't find the theme file, the config file...

Also note, the warning above.

I have compiled it whith mingw/msys under WinXP SP2. I'm running it from a NTFS hard drive.

I have tried also using the command line to specify the config file

Ticket imported from: #2137680. Ticket imported from: bugs/3984.

Change History (18)

comment:1 by bluegr, 12 years ago

I have exactly the same problem using Windows XP and Vista

Here's a sample output when starting IHNM: User picked target 'ihnm' (gameid 'saga')... Looking for a plugin supporting this gameid... Saga engine Starting 'SAGA Engine game' WARNING: md5_file couldn't open 'c:\projects\files\I have no mouth and I must scream\SCREAM.RES'! WARNING: md5_file couldn't open 'c:\projects\files\I have no mouth and I must scream\MUSICGM.RES'! WARNING: md5_file couldn't open 'c:\projects\files\I have no mouth and I must scream\SFX.RES'! WARNING: md5_file couldn't open 'c:\projects\files\I have no mouth and I must scream\MUSICFM.RES'! WARNING: md5_file couldn't open 'c:\projects\files\I have no mouth and I must scream\PATCH.RE_'! WARNING: md5_file couldn't open 'c:\projects\files\I have no mouth and I must scream\SCRIPTS.RES'! WARNING: Saga engine failed to instantiate engine: Unable to locate game data (target 'ihnm', path 'c:\projects\files\I have no mouth and I must scream\')!

comment:2 by fingolfin, 12 years ago

You can safely ignore "WARNING: FilesystemNode::openForReading: FilesystemNode does not exist!" for the time being, it is unrelated.

I commited a fix to the advanceddetector just now, which might have some impact on this. Can you please tell me whether the issue still occurs in rev 34702?

comment:3 by fingolfin, 12 years ago

Owner: set to fingolfin
Summary: ScummVM doens't find filesWIN: ScummVM doesn't find files

comment:4 by bluegr, 12 years ago

Rev 34702 fixed the issue for me :)

comment:5 by SF/mac_es, 12 years ago

Not for me.

It doesn't reach even to Advanced detector.

If I double click the executable, it doesn't find Also it says that is creating a configuration file though I have one in the same directory and I have used -c option in command line.

If I add the fallback to File::open and File::exists everything works (line 112 and line 125)

comment:6 by fingolfin, 12 years ago

Right, I forgot about the config file -- anyway, that should be fixed by now, too. As for the theme file, I'd think that this cause problems because of the missing config file, but maybe I am wrong. Please tell me your experience with rev 34710 or later :).

comment:7 by Kirben, 12 years ago

External files (engine data and theme files) are broken in Windows port, since ScummVM doesn't check the current directory anymore.

comment:8 by SF/mac_es, 12 years ago

The config file works well, theme not. Neither the engine data files. Beside this the other games run well.

comment:9 by fingolfin, 12 years ago

I assume you have the engine data and theme problems because the Windows version "installs" those files into the same dir as the .exe, and then relies on them to be found there, instead of setting up an extrapath & themepath pointing there. I'll think about a solution for this.

comment:10 by Kirben, 12 years ago

Maybe set the default data file path to the current working directory (Not recursive), for Windows port only?

comment:11 by SF/mac_es, 12 years ago

@fingolfin Yes, and the engine data are in the same directory as the .exe BTW, I have setted an extra path for the soundfonts, and I'm getting numerous warnings that the extra path is already added for searching

@kirben It looks well, but what happens if you override it from commandline whith -p option?

comment:12 by eriktorbjorn, 12 years ago

I think those extra warnings happen because of Theme::themeConfigUseable(), which it calls for every file it thinks looks vaguely theme-like:

bool Theme::themeConfigUseable(const Common::String &stylefile, const Common::String &style, Common::String *cStyle, Common::ConfigFile *cfg) { if (ConfMan.hasKey("themepath")) Common::File::addDefaultDirectory(ConfMan.get("themepath"));

#ifdef DATA_PATH Common::File::addDefaultDirectoryRecursive(DATA_PATH); #endif

if (ConfMan.hasKey("extrapath")) Common::File::addDefaultDirectoryRecursive(ConfMan.get("extrapath"));


comment:13 by fingolfin, 12 years ago

I just commited a change which adds the current directory to the end of the SearchSet of the SearchManager. This should hopefully cure the last couple problems you were seeing. Please tell me whether this is the case, or whether it works fine for you now.

Right now I am not sure whether it will stay this way or not, but I am happy enough to add this to the list for now. My main two goals were already reached: 1) catching and fixing code which relied on using relative/absolute paths as arguments to File::open(); 2) forcing all client code to always and unconditionally look up files in the current dir. Now, code can use one of the alternate File::open methods to bypass the SearchMan, and hence the current dir lookup; and also the contents of the current dir are cached just as that of any other search dir.

About the warnings: They are harmless, and Torbjörn described them correctly anyway. These warnings will eventually be fixed, but since Tanoku already did most of the fixing on the gsoc2008-gui branch, I will wait for that to be backported before investing further effort :)

comment:14 by SF/mac_es, 12 years ago


Now works correctly, thanks.

I have read the mail list, how can I set themepath and datapath? In the config file? I have no problem defining them


comment:15 by Kirben, 12 years ago

I noticed the Kyra engine still fails to find 'kyra.dat' in the current directory though.

The Extra Path and Theme Path can be set via the Paths tab, in the Options section of the Launcher, although they are meant to be optional.

comment:16 by fingolfin, 12 years ago

Resolution: fixed
Status: newclosed

comment:17 by fingolfin, 12 years ago

The kyra issue is another one, see bug #2103506.

comment:18 by digitall, 20 months ago

Component: --Unset--Port: Win32
Note: See TracTickets for help on using tickets.