Reading Same file produces different values

[vipergt023]

Hi,

I create a byte array and then copy a string (256 bytes) and two integers (using BitConverter::GetBytes()) into it. I use File::WriteAllBytes() to save it to disk. Then I read it with File::ReadAllBytes(). If I write and read immediately following each other, everything works properly. However, if I write, then do some other stuff, then read, the string comes out ok, but the integers are not correct. Any ideas? Thanks.

Vinoj

[nukefusion]

That would tend to suggest that the problem lies with whatever "stuff" you are doing in between the write and read. What does this other stuff involve?

[vipergt023]

The interesting thing is that the other stuff only involves reading the file (it's a configuration file) and running operations on what it read. There are no write operations. If I kill the program and read the config file again, it reads correctly (indicating that the file hasn't changed). It's only within a single instance of the program that it acts up. Thanks.

[nukefusion]

Okay. Still, without a code sample trying to diagnose the problem is pretty much guesswork.

[vipergt023]

Do you know if there's some Endian conversion that I should be concerned with with the GetBytes() or ReadAllBytes() methods? I'm on a Intel platform.

[nukefusion]

No, not as far as I know. The encoding used when reading and writing is important but I don't think that's your problem. You've already stated that if you read the bytes straight after you've written them then the result is what you'd expect. It's only when you do this 'other stuff' that problems occur. Unfortunately you don't say what the other stuff you are doing is, so I can't really help you.

[vipergt023]

Sorry, I'm not trying to vague, I was trying not to innundate the thread with a bunch of code. The other "stuff" is setting the parameters of a form with the info from the config file, then opening the form, displaying information, then closing the form. The setup of the program is a form (Form1) with a config button and the "stuff" button. If I click the config button right after startup, it works (reads the config file properly). When I click "stuff", it opens the file (properly) and displays the info needed. When I exit the form created by "stuff", it goes back to Form1. Then if I click the config button or "stuff", the read is incorrect. It changes both integers to 0x2 consistently.

Here are my save and open routines:

static void SaveParams(String ^path, int pan, int report)
 {
 
        array<unsigned char>^ dataArray = gcnew array<unsigned char>(MAX_FILENAME+sizeof(int) + sizeof(int));
        //copy file path
        if(path[path->Length-1] != '\\')
            path += "\\";
        //TilePath = TilePath->Replace("\\", "\\\\");
        Encoding^ charBytes = Encoding::ASCII;
        Buffer::BlockCopy(charBytes->GetBytes(path), 0, dataArray, 0, path->Length);
        Buffer::BlockCopy(BitConverter::GetBytes(pan), 0, dataArray, MAX_FILENAME, sizeof(int));
        Buffer::BlockCopy(BitConverter::GetBytes(report), 0, dataArray, MAX_FILENAME + sizeof(int), sizeof(int));
        try{
            File::WriteAllBytes(".\\wiips.cfg", dataArray);
        }
        catch(Exception ^e){
            e->Message;
        }
    }
 
    static String^ OpenParams(int *pan, int *report)
        {
            String ^path;
            try{
                array<unsigned char>^ dataArray = File::ReadAllBytes(".\\wiips.cfg");
                Encoding^ charBytes = Encoding::ASCII;
                path = charBytes->GetString(dataArray, 0, MAX_FILENAME);
                //removes null values from string
                path = path->Remove(path->IndexOf(0));
 
                *pan = BitConverter::ToInt32(dataArray, MAX_FILENAME);
                *report = BitConverter::ToInt32(dataArray, MAX_FILENAME + sizeof(int));
            }
            catch(Exception ^e){
                e->Message;
            }
            return path;
        }

I've checked the code and I only call them and access the file when I intend to. Hope this helps. Thanks for your time.

[nukefusion]

Well, I can't really see anything drastically wrong with the code you've posted, but then you did say you've already tested the save and open methods by running one after the other, with expected results.

The only thing I can say is that the second time you click the button the load can't be working properly and it's probably got something to do with the elusive 'stuff' method, based on the fact that if you restart program the read will work fine once again.

I'd add some breakpoints and step through the code the second time you click the button, checking the variable contents within the watch window of VS to try and track down exactly where this problem is occurring.

[vipergt023]

Do you know if there's a way to flush any buffers or stacks in VS? I'm using static methods to open/save the file so all the variables are local. On the open, the variables are initialized to zero. Also on the open, the data read from the disk is incorrect [string -ok][int - wrong][int-wrong]. Real bizarre.

[nukefusion]

Okay, I would forget about flushing buffers or anything like that because I think that's a red herring.

First off, I would do something with the exceptions that might be thrown during those Open and Save methods. I don't use C++ all the time myself, but it looks like you're doing nothing with the exceptions that are caught. So if exceptions are being thrown during those blocks, you're not going to be aware of it - instead you'll just end up with bizarre behaviour like you're getting at the moment.

I think this line from the Open method looks suspect:

//removes null values from string
path = path->Remove(path->IndexOf(0));
 

If IndexOf(0) can't be found then this will throw an exception which means the next two lines that read the numbers from the file, won't execute. That could lead to the behaviour you're describing because the numbers are not being read back from the file.

Modify your exception handlers and run your code again, see what (if any) errors you catch.

[vipergt023]

It's not hitting any exceptions in my test case. I'm debugging and stepping through it and that's how I'm finding the incorrect reads. Good catch on the IndexOf() line, that would've been an error in certain situations. Any other ideas?

[nukefusion]

Well I ran a test case here in C++ using the code you provided for the save and open methods and it worked fine for me. The only thing I changed in my sample was getting rid of the dereferencing that takes place in the open method, so that the signature looked like this:

 static String^ OpenParams(int pan, int report)
 

and the assignment looked like this:

pan = BitConverter::ToInt32(dataArray, MAX_FILENAME);
report = BitConverter::ToInt32(dataArray, MAX_FILENAME + sizeof(int));
 

If you can confirm that those save and open methods are running okay then the error has got to be occurring elsewhere.

[nukefusion]

vipergt023, have you got any further forward with this?

[vipergt023]

Hi nukefusion,

I've been out of the office for a few days. I haven't gotten any further. I know for sure that those two places are the only places where I'm accessing the file. I step through my form calls and I don't see any place where any problems could be caused. I'm almost out of options unless I try saving with another method, maybe using the filestream class.

[vipergt023]

Now I get something really weird. I rearranged the order of the file to have the integers first, then the string (<int><int><string>). I use the FileStream class to read the bytes in and the order of the array is <string><int><int> - and the ints are wrong. I check the file outside the program using a binary viewer and the data is correct (not swapped). How could this happen?

[nukefusion]

Again, it's hard to say without seeing your code. Did you follow my example in my previous post. I tested it again and it works, so you must be doing something extra to break it that you haven't mentioned here.

Maybe you would be better off creating a serializable class or something.

[vipergt023]

I figured out what it was. During my form load, I had an open file dialog that ended up changing the working directory in memory. I would then open a file with a relative path and it would look somewhere else. Now I have to figure out how to keep the local directory...

[nukefusion]

I'm glad you've finally found the cause of your problem. Thanks for posting back on your progress.