A (minor) limitation of @FileSize...

  • This site uses cookies. By continuing to use this site, you are agreeing to our use of cookies. Learn more.
First, to demonstrate the situation, the following commands and their results:
[Z:\Copy]echo %@Comma[%@fileSize[dos\Deleted.btm,b,a]]
[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:
[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.
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.)
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.)
That could be a little briefer.
v:\4utilcopy> function truesize `%@word[0,%@execstr[pdir /(za) %1]]`
v:\4utilcopy> echo %@filesize[4Utils.ncb]
v:\4utilcopy> echo %@truesize[4Utils.ncb]
v:\4utilcopy> attrib 4Utils.ncb
___A______C____  V:\4utilcopy\4Utils.ncb
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.
Rex, is it WAD that PDIR's /(za) gives a result different from that of %@FILESIZE[,,a]? One (not me) might not like that!
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.