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

  • This site uses cookies. By continuing to use this site, you are agreeing to our use of cookies. Learn more.
#1
Again, the output of a TCC session:

Code:
[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:

Code:
[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!
 
#4
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.
 
#5
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).