WinBoard 4.8.0 writes PGN and debug file in install dir

[Sven]

Former WinBoard versions that I used (the last one was 4.6.2 which is already quite old) stored PGN and debug file in the current working directory from which I started winboard.exe if I specified the options "/sgf FILENAME /debug" on the commandline, with FILENAME not containing a folder. WinBoard 4.8.0 chooses its own installation folder for these files instead, which is surprising for me. The current working directory would still have been the natural place if I did not specify any other path name.

I can live with adding the full path name in front of FILENAME for the /sgf option so the PGN part of the problem can be solved. But why would someone want WinBoard to write user data, or even anything, into the installation folder, where possibly restrictive permissions may even prevent this? My test script starts WinBoard once per opponent in a gauntlet, and since I want it to run unattended I currently see no way to save the debug file from the previous match before WinBoard overwrites it when starting the next match. Can I configure this somehow, without changing the source? Is this a known problem that is already fixed in a later version? What do others do regarding the debug file when using 4.8.0?

EDIT: of course I can add a copy command "winboard.debug -> winboard_whatever.debug" so it can also be solved for the debug file. But I still don't think this is intended.

I did not try the more recent 4.9.1 version since I did not find any official Windows build for it.

Any help would be highly appreciated!

[hgm]

I don't recall I changed anything in that area. But I am not sure there is something like a current working directory in Windows. You double-click winboard.exe to start it, and then what should it assume as working directory?

WinBoard has always expanded filenames relative to its own installation folder. Otherwise we could never have put pre-configured engines in the install. Their directories are described in the engine list of the ini file as relative path names (e.g. /fd="../Fairy-Max"). If they were absolute path names things would cease to work if the user installed in a folder with a different name.

[Sven]

I don't recall I changed anything in that area. But I am not sure there is something like a current working directory in Windows. You double-click winboard.exe to start it, and then what should it assume as working directory?

WinBoard has always expanded filenames relative to its own installation folder. Otherwise we could never have put pre-configured engines in the install. Their directories are described in the engine list of the ini file as relative path names (e.g. /fd="../Fairy-Max"). If they were absolute path names things would cease to work if the user installed in a folder with a different name.

I don't double-click, I start WinBoard with a lot of command line arguments via script. And yes, there *is* a current working directory for each running executable even under Windows, even if you double-click an executable in the Windows explorer.

I am also not talking about path names of engines that may be configured in the ini file (there it is ok if the convention is that relative path names refer to the installation folder, as the ini file kind of specifies the installation), but - especially - I am talking about the folder where WinBoard writes the winboard.debug file which is certainly "user data" and does not belong into the installation folder. Old 4.6.2 wrote it into the current working directory but 4.8.0 writes into the installation folder for some reason. I think that silently writing any file in the installation folder, unless that was specified somehow, is not appropriate.

Maybe the reason is simply some chdir() to the install dir that was not present in older WB, and now there is no chdir() back to the place where it came from.

[hgm]

I checked the code, and WinBoard seems to use two Windows API calls in relation to this: SearchPath and GetFullPathName. At startup it does this:

Code: Select all

  if (SearchPath(NULL, "WinBoard.exe", NULL, MSG_SIZ, installDir, &filepart)) {
    *filepart = NULLCHAR;
    SetCurrentDirectory(installDir);
  } else {
    GetCurrentDirectory(MSG_SIZ, installDir);
  }

which seems to erase all memory of the directory you started from in case SearchPath returns 'true'. If I interpret the description of this callcorrectly, it would find the folder containing a winboard.exe in the 'system search path' or the current directory, the order of preference defined by some registry key. As in your case the current directory is not likely to contain a winboard.exe, the order doesn't really matter, and it would always use the system path.

It could be that the way you installed it makes the difference. If it cannot find any winboard.exe in the 'system seach path' (whatever that means), you would keep the current directory.

[Sven]

I checked the code, and WinBoard seems to use two Windows API calls in relation to this: SearchPath and GetFullPathName. At startup it does this:

Code: Select all

  if (SearchPath(NULL, "WinBoard.exe", NULL, MSG_SIZ, installDir, &filepart)) {
    *filepart = NULLCHAR;
    SetCurrentDirectory(installDir);
  } else {
    GetCurrentDirectory(MSG_SIZ, installDir);
  }

which seems to erase all memory of the directory you started from in case SearchPath returns 'true'. If I interpret the description of this callcorrectly, it would find the folder containing a winboard.exe in the 'system search path' or the current directory, the order of preference defined by some registry key. As in your case the current directory is not likely to contain a winboard.exe, the order doesn't really matter, and it would always use the system path.

It could be that the way you installed it makes the difference. If it cannot find any winboard.exe in the 'system seach path' (whatever that means), you would keep the current directory.

Ok, that might make sense, since I used the installer this time which will certainly have touched the registry somehow. Probably I did not use the installer last time.

Nevertheless, my remark is still valid that the current behaviour is not as I would expect it. Maybe WinBoard/xboard should remember the current directory at program start and use this to build the path name for all files that belong to "user data", like debug file, PGN, or maybe even tournament related files, unless the location of such files is already specified explicitly through some folder.

[hgm]

The problem is that when you start by double-clicking it, the current directory will probably be some obscure system directory. And all user files would go there.

Unlike XBoard, WinBoard is primarily designed for being launched from the GUI. XBoard can afford to (and does) keep the current directory, because all support files it could need (Polyglot, its own piece graphics) are in known locations, and accessed through hard-coded path namesif they are not expected to be in the system path.

One problem is that you cannot always know whether a file is a user file or a system file. E.g. the WinBoard install does come with PGN and FEN files for opening lines and start positions (the Nunn and Silver suite), but it is also very common for the user to provide his own.

One solution I see would be to only make WinBoard change directory to its installation folder when the directory it starts is obviously not what the user would want. The question is how to decide that in a way that works forall Windows versions.