1. This site uses cookies. By continuing to use this site, you are agreeing to our use of cookies. Learn More.

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

Discussion in 'Support' started by mathewsdw, Mar 26, 2013.

  1. mathewsdw

    Joined:
    May 24, 2010
    Messages:
    855
    Likes Received:
    0
    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!
     
  2. rconn

    rconn Administrator
    Staff Member

    Joined:
    May 14, 2008
    Messages:
    9,860
    Likes Received:
    83
    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.
     
  3. mathewsdw

    Joined:
    May 24, 2010
    Messages:
    855
    Likes Received:
    0
    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.
     
  4. Steve Fabian

    Joined:
    May 20, 2008
    Messages:
    3,520
    Likes Received:
    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. mathewsdw

    Joined:
    May 24, 2010
    Messages:
    855
    Likes Received:
    0
    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).
     

Share This Page