S
simon22
Guest
Very strange phenomenon: output file filled or truncated with binary zeros
I have recently encountered a very strange phenomenon which I'm at a loss to account for. I have had reports in the last few weeks from 4 users who say that they have lost data from the file that my application writes to. I have been able to see two of the files. One of them is about 34KB and viewed in a binary editor it contains nothing but binary zeros. The other is about 40MB and if I view it in a binary editor, it is fine up to offset 02600000 (hex), but from 02600000 onwards it contains nothing but binary zeros.
I don't know for sure that all 4 have experienced the same thing, but it sounds as if 3 of them have had very similar truncation, and the 4th has lost everything.
The way my app saves is like this: the app writes to a temporary file. If any error occurs, the save is aborted. If the save succeeds, the original file is deleted and the temporary file is renamed to replace it. None of the users reported any problems when they saved. The problem occurred the next time they tried to view their data.
I estimate the chance that this was caused by a bug in my code as approaching zero. I am a very experienced coder and I have checked it meticulously and can find no way that my code could have done this. The code uses CFile::Write to write to the file. The truncated file actually split a keyword that was being written out. Low-level buffering code might conceivably have done that, and my code does do its own buffering, but this part of the code has not been changed in over 10 years, and has behaved faultlessly throughout that time. If an error did occur, I can think of no way that it would result in binary zeros being output. Also, why do zeros start at hex 02600000? Surely it can't be a coincidence that it starts at a round number that ends in 5 zeros? But this is a round number only in hex terms, and my code doesn't use hex for buffer sizes (or any sizes). All sizes are specified in decimal values.
So I ask myself - Why after years of working fine have I had 4 reports like this in a window of less than 3 weeks? Why binary zeros? Why in the truncation case I say did they start on a (hex) round number?
I have not been able to confirm that they're all using the same version of my software, but it looks like that. That version has been around for just under a year. Why problems now? I only know the Windows versions for two of them. One had Windows 7 and another had Windows 10. One user said they hard recently run a defrag on their hard drive. Could that be relevant? An attempt to defrag an SSD maybe? (I don't know if they have SSDs). A virus? A weird new fault in a service patch, miraculously affecting both Windows 7 and Windows 10?
Any ideas anyone?
Simon
Continue reading...
I have recently encountered a very strange phenomenon which I'm at a loss to account for. I have had reports in the last few weeks from 4 users who say that they have lost data from the file that my application writes to. I have been able to see two of the files. One of them is about 34KB and viewed in a binary editor it contains nothing but binary zeros. The other is about 40MB and if I view it in a binary editor, it is fine up to offset 02600000 (hex), but from 02600000 onwards it contains nothing but binary zeros.
I don't know for sure that all 4 have experienced the same thing, but it sounds as if 3 of them have had very similar truncation, and the 4th has lost everything.
The way my app saves is like this: the app writes to a temporary file. If any error occurs, the save is aborted. If the save succeeds, the original file is deleted and the temporary file is renamed to replace it. None of the users reported any problems when they saved. The problem occurred the next time they tried to view their data.
I estimate the chance that this was caused by a bug in my code as approaching zero. I am a very experienced coder and I have checked it meticulously and can find no way that my code could have done this. The code uses CFile::Write to write to the file. The truncated file actually split a keyword that was being written out. Low-level buffering code might conceivably have done that, and my code does do its own buffering, but this part of the code has not been changed in over 10 years, and has behaved faultlessly throughout that time. If an error did occur, I can think of no way that it would result in binary zeros being output. Also, why do zeros start at hex 02600000? Surely it can't be a coincidence that it starts at a round number that ends in 5 zeros? But this is a round number only in hex terms, and my code doesn't use hex for buffer sizes (or any sizes). All sizes are specified in decimal values.
So I ask myself - Why after years of working fine have I had 4 reports like this in a window of less than 3 weeks? Why binary zeros? Why in the truncation case I say did they start on a (hex) round number?
I have not been able to confirm that they're all using the same version of my software, but it looks like that. That version has been around for just under a year. Why problems now? I only know the Windows versions for two of them. One had Windows 7 and another had Windows 10. One user said they hard recently run a defrag on their hard drive. Could that be relevant? An attempt to defrag an SSD maybe? (I don't know if they have SSDs). A virus? A weird new fault in a service patch, miraculously affecting both Windows 7 and Windows 10?
Any ideas anyone?
Simon
Continue reading...