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

Bias in PDIR

Discussion in 'Support' started by nickles, Jun 28, 2008.

  1. nickles

    Joined:
    Jun 24, 2008
    Messages:
    220
    Likes Received:
    0
    Hi,

    I recently noticed a bias between the output of
    1) PDIR /(zKc sp) and
    2) The file sizes reported by Windows.

    E.g. PDIR /(zKc sp) readme.txt returns "0 E:\temp\down\readme.txt", while Windows - correctly reports - "1 kb" (Explorer).
    Annotation: DIR readme.txt - also correctly - delivers "28.06.2008 19:04 984 readme.txt"

    nickles
     
  2. Steve Fabian

    Joined:
    May 20, 2008
    Messages:
    3,520
    Likes Received:
    4
    nickles wrote:
    | Hi,
    |
    | I recently noticed a bias between the output of
    | 1) PDIR /(zKc sp) and
    | 2) The file sizes reported by Windows.
    |
    | E.g. PDIR /(zKc sp) readme.txt returns "0 E:\temp\down\readme.txt",
    | while Windows - correctly reports - "1 kb" (Explorer). Annotation:
    | DIR readme.txt - also correctly - delivers "28.06.2008 19:04 984
    | readme.txt"

    Verified in TCC 9.02.151 - PDIR always truncates, instead of rounding the
    fractional part of the reporting unit.

    pdir/(zc zk zK fn) reports for a given (test) directory:

    997 0 0 997.txt
    998 0 0 998.txt
    999 0 0 999.txt
    1,000 1 0 1000.txt
    1,001 1 0 1001.txt
    1,002 1 0 1002.txt
    1,003 1 0 1003.txt
    1,004 1 0 1004.txt
    1,022 1 0 1022.txt
    1,023 1 0 1023.txt
    1,024 1 1 1024.txt
    1,025 1 1 1025.txt
    1,026 1 1 1026.txt
    1,027 1 1 1027.txt
    1,028 1 1 1028.txt

    --
    Steve
     
  3. rconn

    rconn Administrator
    Staff Member

    Joined:
    May 14, 2008
    Messages:
    10,090
    Likes Received:
    85
    Steve Fábián wrote:

    WAD -- see the documentation for PDIR.

    Rex Conn
    JP Software
     
  4. nickles

    Joined:
    Jun 24, 2008
    Messages:
    220
    Likes Received:
    0
    Ok, read over this...

    But, what's the sense behind this design?
    Why would one like to have a different result than Windows in that respect?

    Please enlighten me :o!

    Any other switch available (no script)?

    nickles
     
  5. Steve Fabian

    Joined:
    May 20, 2008
    Messages:
    3,520
    Likes Received:
    4
    rconn wrote:
    | Steve Fábián wrote:
    |
    |
    | ---Quote---
    || nickles wrote:
    ||| Hi,
    |||
    ||| I recently noticed a bias between the output of
    ||| 1) PDIR /(zKc sp) and
    ||| 2) The file sizes reported by Windows.
    |||
    ||| E.g. PDIR /(zKc sp) readme.txt returns "0 E:\temp\down\readme.txt",
    ||| while Windows - correctly reports - "1 kb" (Explorer). Annotation:
    ||| DIR readme.txt - also correctly - delivers "28.06.2008 19:04 984
    ||| readme.txt"
    ||
    || Verified in TCC 9.02.151 - PDIR always truncates, instead of
    || rounding the fractional part of the reporting unit.
    | ---End Quote---
    | WAD -- see the documentation for PDIR.

    As usual, you are correct. However, here is the strange report of the
    command
    pdir/(zc 4@filesize[*] zk @filesize[*,k] zK @filesize[*,K] fn)/os

    0 0 0 0 0 0 0000.txt
    1 1 0 1 0 1 0001.txt
    2 2 0 1 0 1 0002.txt
    997 997 0 1 0 1 0997.txt
    998 998 0 1 0 1 0998.txt
    999 999 0 1 0 1 0999.txt
    1,000 1000 1 1 0 1 1000.txt
    1,001 1001 1 2 0 1 1001.txt
    1,002 1002 1 2 0 1 1002.txt
    1,003 1003 1 2 0 1 1003.txt
    1,004 1004 1 2 0 1 1004.txt
    1,022 1022 1 2 0 1 1022.txt
    1,023 1023 1 2 0 1 1023.txt
    1,024 1024 1 2 1 1 1024.txt
    1,025 1025 1 2 1 2 1025.txt
    1,026 1026 1 2 1 2 1026.txt
    1,027 1027 1 2 1 2 1027.txt
    1,028 1028 1 2 1 2 1028.txt

    Notice the zS (where S is a magnitude prefix) truncates (equivalent to using
    the FLOOR function), while %@filesize[*,S] rounds up even 1 byte (as the
    CEILING functon does). In many situations one would like to have something
    closer to the rounding done by @EVAL.
    --
    Steve
     
  6. Steve Fabian

    Joined:
    May 20, 2008
    Messages:
    3,520
    Likes Received:
    4
    nickles wrote:
    | Ok, read over this...
    |
    | But, what's the sense behind this design?
    | Why would one like to have a different result than Windows in that
    | respect?
    |
    | Please enlighten me :o!
    |
    | Any other switch available (no script)?

    Dear nickles:

    Since you did not quote anything, I am not certain what you are complain
    about, but I think you are referring to the differences between Windows
    Explorer's file size reporting vs. TCC reporting. TCC will always report the
    exact size, no matter how large the file, if you do not specify that you
    want only an approximate size (by specifying a reporting size larger than
    bytes). If you know the allocation unit of another device, only the exact
    size allows you to determine in advance whether or not that device has space
    to receive a copy of the file.

    TCC is designed for operations that "pure vanilla" Windows (i.e., without
    additional programs not included by MS) does not support. That's why it has
    so many features, and why in many instances it differs from MS reports.
    --
    Steve
     

Share This Page