Opening files with unix file endings under windows
Author
Im trying to debug a very wierd error here. Im opening a lot of xml files, in debug mode (Visual Studio) all of them work, but in release, only some of them work. A common characteristics Ive found among them is that the files that cant be opened has unix file endings.
Could this be a problem? I open them using std::fstream, which I thought would be able to handle it.
A few days ago when hunting for the solution, I found out that I didnt null terminate the char* arrays that holds the file contents. Its fixed now, but some files still resists.
The actual error I get is that is that in the buffer I get one or two bogus characters and nothing more. Except for some junk at the end of the file, but its there regardless, as long as the file is opened. Ive always guessed that it was some sort of binary metadata.
Any pointers very much appreciated. :)
Quote:Original post by Mizipzor
Im trying to debug a very wierd error here. Im opening a lot of xml files, in debug mode (Visual Studio) all of them work, but in release, only some of them work. A common characteristics Ive found among them is that the files that cant be opened has unix file endings.
Are you sure it's not a permissions problem? I have a theory (that you're free to dispel) that the files that have UNIX line endings may have been saved on UNIX with ownership/permissions that do not allow you to open the files. Can you open the files in an editor on the same system, for example?
Quote:Could this be a problem? I open them using std::fstream, which I thought would be able to handle it.
The line endings aren't encoded as a property of a file i.e. an fstream can't know what the line endings are before you open the file, so I doubt this has anything to do with your problem.
Use:
std::ifstream myfile("path\\to\\file.xml", std::ios::binary);Quote:
The actual error I get is that is that in the buffer I get one or two bogus characters and nothing more. Except for some junk at the end of the file, but its there regardless, as long as the file is opened. Ive always guessed that it was some sort of binary metadata.
Now it sounds like either a parsing problem or you passing incorrect flags to the fstream/ifstream constructor. But earlier you said you couldn't *open* these files, so which is it? Or is it both?
Quote:Original post by Mizipzor
A few days ago when hunting for the solution, I found out that I didnt null terminate the char* arrays that holds the file contents. Its fixed now, but some files still resists.
char * raises red flag. Are you overflowing buffers?
Quote:The actual error I get is that is that in the buffer I get one or two bogus characters and nothing more. Except for some junk at the end of the file, but its there regardless, as long as the file is opened. Ive always guessed that it was some sort of binary metadata.
XML files specify character encoding. Does your parser support them correctly? What about unicode?
An easy way to check if the line endings are your problems is to grab an implementation of unix2dos (such as from cygwin), transform the files and see if you get the same results.
Opening a file as text mode changes the way newlines are handled. I don't remember exactly, but under Windows it's either "\n" becomes "\r\n", or the other way around.
That causes ftell and fseek (And the fstream equivalents) to be a little confusing sometimes. Are you using either of them?
That causes ftell and fseek (And the fstream equivalents) to be a little confusing sometimes. Are you using either of them?
Author
Im on to something now. I opened the file in a hex editor and saw that three bytes were at the beginning of every failed that caused the error. I dont know how they got there, I created the file with a script I wrote in python, using its built-in xml parser.
I can load and read them now, but somehow, I feel that this issue will come back and bite me.
I can load and read them now, but somehow, I feel that this issue will come back and bite me.
This topic is closed to new replies.
Advertisement
Popular Topics
Advertisement
