Sign in to follow this  

Opening files with unix file endings under windows

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

If you intended to correct an error in the post then please contact us.

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 this post


Link to post
Share on other sites
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?

Share this post


Link to post
Share on other sites
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?

Share this post


Link to post
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 this post


Link to post
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 this post


Link to post
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 this post


Link to post
Share on other sites

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

If you intended to correct an error in the post then please contact us.

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now

Sign in to follow this