| | |
ofstream corrupting file when program terminated
Please support our C++ advertiser: Intel Parallel Studio Home
![]() |
•
•
Join Date: Nov 2008
Posts: 8
Reputation:
Solved Threads: 0
Hi,
Some time ago, I wrote a program that used the write() function of an fstream object to write a large file to a 100MB-zip-disk (it was an old computer). When I "End Now"ed the program I found that the zip disk was corrupted. The file didn't show up but a lot of the free space was gone, and I had to format the disk.
I'm guessing it was because the close() function was never called, and so the result would have been the same if I had run the program on my hard drive (which I'm glad I didn't). Is there any way of getting around this problem?
I know there's an atexit() function, but I tried it with cout and it crashed.
Thanks for your time
Some time ago, I wrote a program that used the write() function of an fstream object to write a large file to a 100MB-zip-disk (it was an old computer). When I "End Now"ed the program I found that the zip disk was corrupted. The file didn't show up but a lot of the free space was gone, and I had to format the disk.
I'm guessing it was because the close() function was never called, and so the result would have been the same if I had run the program on my hard drive (which I'm glad I didn't). Is there any way of getting around this problem?
I know there's an atexit() function, but I tried it with cout and it crashed.
Thanks for your time
Even if your program doesn't "close" the file, the run-time library will, and failing that the OS will do it when the process terminates.
On a hard disk, the worst that could ever happen would be lost sectors. NTFS is pretty robust against such things (extreme case is power loss, and disks routinely pass this test without severe damage).
ZIP-drives were not exactly the most reliable technology as I recall, so it could just as well have been buggy drivers as your code.
If you're just using the standard library I/O mechanism, there are a lot of steps between your code and the surface of the disk. Any of which could go wrong in a spectacular fashion.
On a hard disk, the worst that could ever happen would be lost sectors. NTFS is pretty robust against such things (extreme case is power loss, and disks routinely pass this test without severe damage).
ZIP-drives were not exactly the most reliable technology as I recall, so it could just as well have been buggy drivers as your code.
If you're just using the standard library I/O mechanism, there are a lot of steps between your code and the surface of the disk. Any of which could go wrong in a spectacular fashion.
•
•
Join Date: Nov 2008
Posts: 8
Reputation:
Solved Threads: 0
I'm really sorry about this: I have no idea what's going on now. I've ran the same program and it's produced a different result.
Last time, the file that was created didn't even show up until the program exited (just after when the close() function was called), and that's why when lots of disk space was taken up but no file produced anywhere I blamed the close() function not being called. And I did search for that file, pressed F5, everything.
This time, the file was produced right at the start and it's size just kept increasing. Plus, when I tried to close the program it just closed without windows saying "this program is not responding. do you want to End Now". I've been trying the whole morning and I can't get it to crash like last time.
If anyone knows what's going on that'll be brilliant, but I think it was probably just the computer misbehaving. Or maybe windows updated itself at some point.
PS
The code was just a normal
And I wondered whether it was the "ios::app" that did something funny, but it's not that either.
Last time, the file that was created didn't even show up until the program exited (just after when the close() function was called), and that's why when lots of disk space was taken up but no file produced anywhere I blamed the close() function not being called. And I did search for that file, pressed F5, everything.
This time, the file was produced right at the start and it's size just kept increasing. Plus, when I tried to close the program it just closed without windows saying "this program is not responding. do you want to End Now". I've been trying the whole morning and I can't get it to crash like last time.
If anyone knows what's going on that'll be brilliant, but I think it was probably just the computer misbehaving. Or maybe windows updated itself at some point.
PS
The code was just a normal
C++ Syntax (Toggle Plain Text)
... fstream file("rubbish.bin",ios::out|ios::binary|ios::app); for(/*some random condition*/){ file.write(/*some random data*/); } ...
And I wondered whether it was the "ios::app" that did something funny, but it's not that either.
•
•
Join Date: Nov 2008
Posts: 8
Reputation:
Solved Threads: 0
Fine, if you insist:
As I say though, it's working fine now. And I've tried "End Process Tree"ing it, it was still working fine. It was probably just the computer misbehaving back then. Maybe there was some other program (I have changed the anti-virus from F-Secure to Sophos - don't know if that could have affected it) or something. Or maybe it was just an out-of-date zip drive driver.
C++ Syntax (Toggle Plain Text)
#include <fstream> #include <iostream> #include <iomanip> using namespace std; void main() { char* data=new char[10<<20]; unsigned int size; cout<<"Size (in MB, to the nearest 10):\n\t"; cin>>size; size=size/10; cin.ignore(0x7fffffff,'\n'); cout<<"\n\nData written (MBs):\t 0..."; //4 spaces fstream file("RandomRubbish.bin",ios::out|ios::binary); for(int MB=1;MB<=size;MB++) { for(int i=0;i<(10<<20)-8;i+=8){ (*reinterpret_cast<unsigned long long int*>(data+i))++; } file.write(data,10<<20); if(file.bad()){ cout<<"\a\a\a\a\a\n\nFile bad!!\n\n"; for(int i=0;i<20;i++)cout<<'\a'; //To get my attention cin.get(); return; } cout<<"\b\b\b\b\b\b\b\b"<<setw(4)<<MB<<"0..."; } cout<<"\n\nDone.\a\n\n"; cin.get(); }
As I say though, it's working fine now. And I've tried "End Process Tree"ing it, it was still working fine. It was probably just the computer misbehaving back then. Maybe there was some other program (I have changed the anti-virus from F-Secure to Sophos - don't know if that could have affected it) or something. Or maybe it was just an out-of-date zip drive driver.
![]() |
Similar Threads
- Trouble with multi-file program (C++)
- adding wav file to program (C#)
- Trying to write to a file so that another program can read from it at the same time (C++)
- PLEASE HELP about Using C# to add an executable file to my program! (C#)
- Lost all file program associations (Windows NT / 2000 / XP)
- Unknown file/program (Viruses, Spyware and other Nasties)
Other Threads in the C++ Forum
- Previous Thread: please help, winsock2 10061 error
- Next Thread: Modular Programming ???
| Thread Tools | Search this Thread |
api array based binary c++ c/c++ calculator char char* class classes code coding compile console conversion count database delete deploy desktop developer directshow dll download dynamic dynamiccharacterarray email encryption error file forms fstream function functions game givemetehcodez google graph gui homeworkhelp iamthwee ifstream input int integer java lib linkedlist linker linux list loop looping loops map math matrix memory multiple news number numbertoword output parameter pointer problem program programming project python random read recursion recursive reference return rpg sorting string strings struct temperature template templates test text text-file tree unix url variable vector video visualstudio win32 windows winsock wordfrequency wxwidgets






