× The internal search function is temporarily non-functional. The current search engine is no longer viable and we are researching alternatives.
As a stop gap measure, we are using Google's custom search engine service.
If you know of an easy to use, open source, search engine ... please contact support@midrange.com.



Well, folders don't normally contain actual data.  They're really just a
place to contain filenames, pointers to files (i.e. FAT entries), or
something that files can point to depending on the file system. Also,
the OS will store attributes about all files and folders.  Those
attributes may or may not be reported as part of the size of the object,
depending on the OS and possibly on the commands being used.  

Also, some filesystems automatically pre-allocate additional space for
each object on the assumption that it might grow.  By doing this, if the
file grows within the additioanl pre-allocated space, it won't get
fragmented on disk.

I don't think what you're seeing represents any problems; just the
differences between the file systems and how they choose to present data
about file & folder sizes.

If you're retrieving the value to help you determine how many bytes to
read from a file, winSize looks like the best bet.  If you want to find
out how much space the file/folder is consuming on disk, perhaps for a
report on disk consumption, WinSizeOnDisk is obvisously the better
choice.

John A. Jones, CISSP
Americas Information Security Officer
Jones Lang LaSalle, Inc.
V: +1-630-455-2787  F: +1-312-601-1782
john.jones@xxxxxxxxxx

-----Original Message-----
From: midrange-l-bounces@xxxxxxxxxxxx
[mailto:midrange-l-bounces@xxxxxxxxxxxx] On Behalf Of Bill Meecham
Sent: Friday, May 06, 2005 9:29 AM
To: Midrange Systems Technical Discussion
Subject: Re: Windows vs stat() Directory Size


folderName=813
Contains 1 text file 4 bytes 

winSize=4 bytes
st_Size=8192

winSizeOnDisk=4096 bytes
st_allocSize=8192
For this small example the allocated size is doubled.


For larger folders I add up all of the folder sizes within the folder
and in one case get

winSizeOnDisk=4,251,648 bytes
st_allocSize sum=118784 bytes

thanks


  ----- Original Message -----
  From: Jones, John (US)
  To: Midrange Systems Technical Discussion
  Sent: Friday, May 06, 2005 9:45 AM
  Subject: RE: Windows vs stat() Directory Size


  No idea for sure but a couple of guesses:

  - Actual vs. allocated size (Windows equivalent is probably 'Size' vs.
  'Size on Disk')
  - 1000 bytes/K vs. 1024 bytes/K

  How different is 'very'?  Can you provide an example or two?

  John A. Jones, CISSP
  Americas Information Security Officer
  Jones Lang LaSalle, Inc.
  V: +1-630-455-2787  F: +1-312-601-1782
  john.jones@xxxxxxxxxx

  -----Original Message-----
  From: midrange-l-bounces@xxxxxxxxxxxx
  [mailto:midrange-l-bounces@xxxxxxxxxxxx] On Behalf Of Bill Meecham
  Sent: Friday, May 06, 2005 7:58 AM
  To: Midrange Systems Technical Discussion
  Subject: Windows vs stat() Directory Size

  Hello,

  i have a pgm that retrieves the allocated size of a directory using
  readdir() and lstat() and stores the dir name and size in a file which
I
  then graph for historic size allocation and reporting.

  when I map the ifs to winexplorer and look at the properties of a
  directory the allocated size is very different.  

  Anyone know why?

  thanx
  bill
  --
  This is the Midrange Systems Technical Discussion (MIDRANGE-L) mailing
  list To post a message email: MIDRANGE-L@xxxxxxxxxxxx To subscribe,
  unsubscribe, or change list options,
  visit: http://lists.midrange.com/mailman/listinfo/midrange-l
  or email: MIDRANGE-L-request@xxxxxxxxxxxx Before posting, please take
a
  moment to review the archives at
http://archive.midrange.com/midrange-l.




  This email is for the use of the intended recipient(s) only.  If you
have received this email in error, please notify the sender immediately
and then delete it.  If you are not the intended recipient, you must not
keep, use, disclose, copy or distribute this email without the author's
prior permission.  We have taken precautions to minimize the risk of
transmitting software viruses, but we advise you to carry out your own
virus checks on any attachment to this message.  We cannot accept
liability for any loss or damage caused by software viruses.  The
information contained in this communication may be confidential and may
be subject to the attorney-client privilege. If you are the intended
recipient and you do not wish to receive similar electronic messages
from us in the future then please respond to the sender to this effect.

  --
  This is the Midrange Systems Technical Discussion (MIDRANGE-L) mailing
list
  To post a message email: MIDRANGE-L@xxxxxxxxxxxx
  To subscribe, unsubscribe, or change list options,
  visit: http://lists.midrange.com/mailman/listinfo/midrange-l
  or email: MIDRANGE-L-request@xxxxxxxxxxxx
  Before posting, please take a moment to review the archives
  at http://archive.midrange.com/midrange-l.
--
This is the Midrange Systems Technical Discussion (MIDRANGE-L) mailing
list To post a message email: MIDRANGE-L@xxxxxxxxxxxx To subscribe,
unsubscribe, or change list options,
visit: http://lists.midrange.com/mailman/listinfo/midrange-l
or email: MIDRANGE-L-request@xxxxxxxxxxxx Before posting, please take a
moment to review the archives at http://archive.midrange.com/midrange-l.




This email is for the use of the intended recipient(s) only.  If you have 
received this email in error, please notify the sender immediately and then 
delete it.  If you are not the intended recipient, you must not keep, use, 
disclose, copy or distribute this email without the author's prior permission.  
We have taken precautions to minimize the risk of transmitting software 
viruses, but we advise you to carry out your own virus checks on any attachment 
to this message.  We cannot accept liability for any loss or damage caused by 
software viruses.  The information contained in this communication may be 
confidential and may be subject to the attorney-client privilege. If you are 
the intended recipient and you do not wish to receive similar electronic 
messages from us in the future then please respond to the sender to this effect.


As an Amazon Associate we earn from qualifying purchases.

This thread ...

Follow-Ups:

Follow On AppleNews
Return to Archive home page | Return to MIDRANGE.COM home page

This mailing list archive is Copyright 1997-2024 by midrange.com and David Gibbs as a compilation work. Use of the archive is restricted to research of a business or technical nature. Any other uses are prohibited. Full details are available on our policy page. If you have questions about this, please contact [javascript protected email address].

Operating expenses for this site are earned using the Amazon Associate program and Google Adsense.