C++ system("rm") not deleting properly?

I wrote a program that, once it's done generating some data and putting it in a file, if the file is not a certain number of lines long it is deleted. Due to the nature of this, it generates and removes files a lot before leaving one behind it likes, so the "rm" command is executed a lot. Is it possible that this command may not work properly, resulting in some trace remnants on the hard disk?

The reason I ask is that I have a MacBook with a 120GB hard drive and prior to running this program I had about 40 GB free. I let the program run all morning and just got a warning that my hard disk was almost full! I looked and I had ~200 MB left. I killed the program using 'ctrl-C' and checked to be sure it was deleting the files properly, and it appears that it was. It had generated 85 files that it kept (each ~1/2KB in size), though in its execution it had generated and supposedly deleted countless hundreds or thousands of files. Those files did not show up when I did an 'ls -a', so they don't seem to be hiding.

Does anyone have any thoughts about this issue? I rebooted the computer and now it says I have 1-2 GB left (for some reason it changes every minute or so from, say, 1.45 GB to 1.71 GB to 1.36 GB etc. etc.). Doing a manual check of all directories in /, I can only account for ~75GB of the total 111GB available for use that's not being used by the operating system.

First, you shouldn't use system("rm") at all. It's unbearably slow. Just use the std::remove() standard function from <cstdio>.

That said, are you closing the file descriptors properly? The files, even if unreferenced in the file system, won't be deleted if any program still has an open descriptor.

Quote:

---

Originally Posted by CornedBee

First, you shouldn't use system("rm") at all. It's unbearably slow. Just use the std::remove() standard function from <cstdio>.

---

Agreed. Or use the system call "unlink" to do the same thing (but less portable, and I doubt there's any performance benefit unless you are deleting thousands of files

Quote:

---

That said, are you closing the file descriptors properly? The files, even if unreferenced in the file system, won't be deleted if any program still has an open descriptor.

---

If we ignore bugs in the filesystem (which one would suspect are few and far between in Mac OS X), the file should however go away once the application has closed the file (or application exits, e.g. when pressing CTRL-C).

--
Mats

When I close the file, I use

infile.clear(); infile.close();

I believe this is the correct way to do it (or, rather, it's always worked in the past). After my initial post, my computer slowly "found" all the hard disk space it had lost. Interestingly, I let my computer sit idly for several hours and slowly the amount of available disk space increased from the 100 MB it had gone down to all the way back up to where it should have been. I'm guessing that all the write/delete operations the program was doing really messed up the computer's accounting system so it only thought it was out of hard disk space when in fact it wasn't. After about 5 hours it had rediscovered the ~30 GB of free space it had "lost".

For future benefit I will look into how to use std::remove(). Thanks!

Have you tried a disk utility? In such case, it might mean some internal of the filesystem is messed up.
It might just be as you say if that's the case, that the disk is unstable?

Otherwise you could keep your file in memory until it is large enough at which point you write it to disk. If not, then you just discard it. It shouldn't consume so much memory or spam the hard drive with files.