# Opening files with unix file endings under windows

This topic is 3602 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

## Recommended Posts

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. :)

##### Share on other sites
Quote:
 Original post by MizipzorIm 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?

##### Share on other sites
Quote:
 Original post by MizipzorA 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?

##### Share on other sites
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.

##### Share on other sites
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?

##### Share on other sites
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.

##### Share on other sites
I suspect that would be a Unicode BOM of some description. Make sure you and your library are handling Unicode correctly? (From use of char* it seems unlikely).

1. 1
Rutin
28
2. 2
3. 3
4. 4
5. 5

• 13
• 11
• 10
• 13
• 20
• ### Forum Statistics

• Total Topics
632950
• Total Posts
3009424
• ### Who's Online (See full list)

There are no registered users currently online

×

## Important Information

We are the game development community.

Whether you are an indie, hobbyist, AAA developer, or just trying to learn, GameDev.net is the place for you to learn, share, and connect with the games industry. Learn more About Us or sign up!

Sign me up!