bluap Report post Posted October 24, 2007 Just noticed this. If you have NEW_FILE_IO defined then the notepad will not load, its fine without. The error log says: notes.xml:1: parser error : Document is empty ^ notes.xml:1: parser error : Start tag expected, '<' not found ^ If you delete notes.xml and let the client create a new one. The file written looks fine but will not load again giving the same error. I'm using latest CVS with various options normally but tested with just NOTEPAD - which works OK, and with NEW_FILE_IO and NOTEPAD - which gives the error. I'm on Debian stable + a bit of testing. Other xml loading stuff works fine either way. I'm trying to get my head around how NEW_FILE_IO works but its a bit complex so I've not found the problem yet. This issue may well be related to previous troubles here. Share this post Link to post Share on other sites
Torg Report post Posted October 25, 2007 Just noticed this. If you have NEW_FILE_IO defined then the notepad will not load, its fine without. The error log says: notes.xml:1: parser error : Document is empty ^ notes.xml:1: parser error : Start tag expected, '<' not found ^ Ahhhh, I discovered the same behaviour when testing my mines.xml file. There is a bug in NEW_FILE_IO that causes something odd to happen when reading the XML files if the file exists in more that one of the directories NEW_FILE_IO searches. This is probably a result of a patch to NEW_FILE_IO that I added to fix a problem with auto-updates and NEW_FILE_IO (I added searching the config dir). Looking at ttl's comments in the other thread I think rather than adding config_dir to the searched paths, the call for auto-updates should be changed to the alternate wrapper (if it exists) to check the config dirs rather than the one currently in use to check the data dirs. That all said, I think this shows a secondary bug which is that for some reason if a file exists twice it crashes something else. How and why that occurs I have no idea at the moment. Share this post Link to post Share on other sites
bluap Report post Posted October 29, 2007 (edited) Well I've found the problem and I can make it work but I think the author of the io/elfile.cpp should check this out. The problem occurs in the el_file constructor when an extra path is specified and the file exists in that path. The call to file_exist_in_dir() returns true but the file is never opened. notes.xml appears to be unique in this. Many other tests are made here for other files but they all fail and the code goes on to try all the paths in path_list; eventually succeeding. If you switch file_exist_in_dir() for open_if_exist(), the notes.xml file opens fine. Index: io/elfile.cpp =================================================================== RCS file: /cvsroot/elc/elc/io/elfile.cpp,v retrieving revision 1.15 diff -a -u -r1.15 elfile.cpp --- io/elfile.cpp 16 Oct 2007 23:56:52 -0000 1.15 +++ io/elfile.cpp 30 Oct 2007 00:03:59 -0000 @@ -160,7 +160,7 @@ if (!extra_path.empty()) { - if (file_exist_in_dir(extra_path + file)) + if (open_if_exist(extra_path + file, uncompress)) { return; } edit: make the change simpler. Edited October 30, 2007 by bluap Share this post Link to post Share on other sites
Torg Report post Posted October 30, 2007 Many other tests are made here for other files but they all fail and the code goes on to try all the paths in path_list; eventually succeeding. If you switch file_exist_in_dir() for open_if_exist(), the notes.xml file opens fine. Yes, the desired outcome of that function is to open the file. Therefore, your change is correct. It shall be patched shortly. Thanks. :-) Share this post Link to post Share on other sites
