Maybe Maybe I'm being stupid (again), but a simple question...

[mathewsdw]

Again, the output of a TCC session:

[Z:\]*dir e1*
 3/26/2013  17:02          10,004  e10,000.txt

[Z:\]del "e10,000.txt"
Deleting Z:\e10,000.txt
     1 file deleted              8,192 bytes freed

As far as I know, neither the drive nor that file are compressed (I don't use compression).

And it gets even stranger. Look at the below, where I repeated the above:

[Z:\]*dir e1*
 3/26/2013  17:02          10,004  e10,000.txt

[Z:\]del "e10,000.txt"
Deleting Z:\e10,000.txt
     1 file deleted            204,800 bytes freed

204,800 bytes free when deleting a 10,004 byte file? Obviously compression has nothing to do with this!

 

[rconn]

DEL saves the free space before deleting a file, then compares it to the free space after deleting the file. If you have other processes writing to the disk at the same time, you're going to get some strange looking results. But it's not a TCC bug.

 

[mathewsdw]

Thank you, Rex. I'm not aware of any other processes (that I explicitly started) running when I do this, but at least it's a sensible answer.

 

[Steve Fabian]

What kind of drive is iZ:? Is it a virtual or an network disk? If so, you may have some delayed operations, it may also have built-in compression. Was the file originally large, and later truncated? You could do that easily in any HLL, or even in TCC using the @fileopen family of functions; possibly the file had been truncated, but the freed up space not returned to the pool of free space until triggered (garbage collection methods?). These are alternate mechanisms which may have kept available disk space not included in the free space (though some of them would make installing to the drive when free space is tight very inefficient. These are only potential mechanisms leading to your observations, none of which is known to be actually used in any file system.

 

[mathewsdw]

Steve, drive Z: is a RAM disk that I've been using for many years (it's my work area that avoids cluttering up and fragmenting a real hard disk). I've never noticed this before on that "disk" (which, again, I've been using for many years).