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

A (minor) limitation of @FileSize...

Discussion in 'Support' started by mathewsdw, Jan 6, 2013.

  1. mathewsdw

    Joined:
    May 24, 2010
    Messages:
    855
    Likes Received:
    0
    First, to demonstrate the situation, the following commands and their results:
    Code:
    [Z:\Copy]echo %@Comma[%@fileSize[dos\Deleted.btm,b,a]]
    36,864
     
    [Z:\]PDir /(zca zc fpn) Z:\DOS\Deleted.btm
             12,288          34,422 Z:\DOS\Deleted.btm
    
    At first, this kind of surprised me, but then I remembered the (probable!) reason:
    Code:
    [Z:\]attrib Z:\dos\Deleted.btm
    ___A______C____  Z:\dos\Deleted.btm
    
    I'd turned disk compression on on my RAM disk a while back and had entirely forgotten about it (no surprise, there!).

    Now I'll note that there are a lot of arguments for/against disk compression, and I don't intend to get into any of them. I'll just note three things:

    #1. I do not have compression turned on for any of my physical hard disks, just the RAM disk which isn't all that large (234 Megabytes).

    #2. I have been told (although I fully admit that I know of no simple way of verifying this) that for small files (which most of the files on my RAM disk are most of the time), compression has very low, if not essentially zero, cost. This is because files less than one cluster in size are not compressed at all.

    #3. I've never noticed anything even close to a performance hit on this RAM disk, virtually all disk operations are effectively instantaneous. That could be because the CPU in this laptop is dual-core with a clock speed greater than 3GHz, but if that's the case it means that compression is probably worthwhile even in (at least some) directories of my physical hard disks.

    And to verify just how little performance impact there is, I copied the entire contents of the RAM disk to another RAM disk and timed it. This was 676 files, (only) 6,230,016 bytes so maybe not a real good test, but it is a RAM disk and space is quite limited. It takes only 1.61 seconds to do this copy, which isn't a whole lot of time by any measure. (In fact, this is making me consider compressing some directories on my hard disk(s).)

    So the bottom line is that I think that there should be at least one way to get @FileSize to report the true amount of disk space taken up by a file, not just it's "theoretical" size.
     
  2. mathewsdw

    Joined:
    May 24, 2010
    Messages:
    855
    Likes Received:
    0
    An easy workaround: Function TrueFileSize=`%@Trim[%@Replace[^,,,%@ExecStr[PDir %1 /(ZCA)]]]`

    Just due to the wonders of TCC! (Although my original comment still remains valid.)
     
  3. rconn

    rconn Administrator
    Staff Member

    Joined:
    May 14, 2008
    Messages:
    9,870
    Likes Received:
    83
    WAD -- @FILESIZE returns the size as reported by Windows.

    If you want to request a new function returning the compressed size, submit it in the Feedback forum.
     
  4. vefatica

    Joined:
    May 20, 2008
    Messages:
    7,971
    Likes Received:
    30
    That could be a little briefer.
    Code:
    v:\4utilcopy> function truesize `%@word[0,%@execstr[pdir /(za) %1]]`
     
    v:\4utilcopy> echo %@filesize[4Utils.ncb]
    19729408
     
    v:\4utilcopy> echo %@truesize[4Utils.ncb]
    9355264
     
    v:\4utilcopy> attrib 4Utils.ncb
    ___A______C____  V:\4utilcopy\4Utils.ncb
     
  5. vefatica

    Joined:
    May 20, 2008
    Messages:
    7,971
    Likes Received:
    30
    Rex, is it WAD that PDIR's /(za) gives a result different from that of %@FILESIZE[,,a]? One (not me) might not like that!
     
  6. vefatica

    Joined:
    May 20, 2008
    Messages:
    7,971
    Likes Received:
    30
    Actually, it would seem that @FILESIZE[,,a] should give the compressed size since that's how much disk space is being used by the file.
     
  7. mathewsdw

    Joined:
    May 24, 2010
    Messages:
    855
    Likes Received:
    0
    Well, Vince, I agree with you in that that's what %@FileSize[xxx,b,a] should report. But as Rex as indicated, he's just using a Windows API function, and it does what it does (and our opinion(s) on how stupid that really is really don't count!). As far as your "improved" function goes, you are right, I just did what I did off the "top of my head" without thinking about it too deeply (and that meant I just used and did the "standard" things I do on a regular basis).

    And Rex, I've already written function(s) that do exactly what I want to do, so I'm not sure it's worth adding/changing anything unless somebody else has got a specific request. But thank you.
     

Share This Page