GNOME Bugzilla – Bug 345941
data-io opens files in wrong mode
Last modified: 2006-06-30 20:48:45 UTC
The function get_ostream in data-io.cc opens the stream in the wrong mode on windows. Streams are in text mode by default on windows. Since FileReader is opening files in binary mode this results in \r being added onto retreived data. Because of this the article cache was not able to create any files, nor could it open any existing files. Here is the simple fix for get_ostream: std::ofstream * o (new std::ofstream (tmp.c_str(), std::ios_base::out|std::ios_base::binary)); Also, on a diagnostic issue, ArticleCache::add should output a debug message if fp==0. The "Unable to save" message could be re-used here.
I'm sure that none of Pan's data files are binary anymore. Would it make more sense to just use text mode throughout?
I think it's easier to stick with binary. At least that way when someone tries to use their pan data on multiple os's it should just work. At least I think I remember someone dual booting windows & linux wanting to use pan on both.
Created attachment 68076 [details] [review] simple patch to open datafiles in binary mode and to log an error on failure
Created attachment 68078 [details] [review] another can't-write-file error notification, this time in article-cache::add
I'm wondering if this is actually the cause of the problem you're seeing. article-cache doesn't use the data-io ostream code -- it saves messages via fopen "wb" and reads them via fopen "rb" or g_file_get_contents.
*** Bug 345787 has been marked as a duplicate of this bug. ***
The problem was that the messasge id's would have \r characters at the end. When data-io wrote the group files in text mode they had \r\n line endings. Then LineReader would read in binary mode looking for \n as the end leaving the \r in the message id and probably other lines as well. Of course each time the group file was saved another \r would be added. I could see those characters in gdb. Since filenames can't have \r, the cache could not create the file. It also prevented matching articles that were already in the cache since their message ids didn't have the extra characters.
Ah, that makes perfect sense.