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

How to? Find out the total allocated size of a directory tree...

Discussion in 'Support' started by mathewsdw, Dec 30, 2012.

  1. mathewsdw

    Joined:
    May 24, 2010
    Messages:
    855
    Likes Received:
    0
    Rex has indicated to me that the above is already possible in TCC, but he didn't tell me how to do it. Yes, "%@FilesSize[/S *,b,a]" will return the total allocated size of all of the files in the current directory tree, but that number is not the total size of the directory tree because it doesn't include the allocated size(s) of the directory "files" (for want of a better term) themselves (which, of course, are not really files and therefore not counted (as far as I can tell) by '%@FileSize"). How does one determine the total allocated size of a directory tree, directory "files" as well as the files themselves? The point is to know whether a given directory tree will fit on a flash drive of a given size/what size flash drive is needed to hold a given directory tree.
     
  2. vefatica

    Joined:
    May 20, 2008
    Messages:
    8,129
    Likes Received:
    33
    "Directory files", as you called them, don't have an allocated size (or rather their allocated size is zero because they contain no **data**). Directories are merely logical structures, entries in the volume's MFT (master file table, SystemVolumeInformation?). Files use space in the MFT, too, but the amount of such space (used by anything), is not (readily, at least) available to, nor should it be of any interest to, the user.
     
  3. mathewsdw

    Joined:
    May 24, 2010
    Messages:
    855
    Likes Received:
    0
    Vince, I am aware the small files fit entirely in the MT. I was also under the distinct impression that small directories are contained there also, but large directories are not contained in the MFT just as large files are not contained in the MFT. But the real bottom line is that that is irrelevant to me: My only goal (and I really don't care how I achieve it) is to figure out how much allocated space a directory will take up on a flash drive/FAT volume so I can know ahead of time if the directory tree will fit. And this has actually come up because @FileSize[/S *,b,a] came up with a number that indicted the directory tree would fit on the flash drive, but when it came right down to it (i.e., actually trying to copy it there) it did not fit. Maybe what I want to accomplish is basically impossible. (I am also aware that the amount of space taken up will vary according to the cluster size of the FAT volume. But the bottom line is that fact only makes it more impossible because even @FileSize[/S *,b,a] won't give the correct results, particularly if the cluster size of the FAT volume is larger than the cluster size of the source drive.)
     
  4. rconn

    rconn Administrator
    Staff Member

    Joined:
    May 14, 2008
    Messages:
    10,092
    Likes Received:
    85
    Directories are always 0 bytes, and don't take up any space on the file system, regardless of the number of files in the directory.

    There isn't any internal function or command in TCC that will convert allocated space on NTFS to that on a random FAT / VFAT drive. The only way to do that is for you to loop through every directory & file, compute the allocation space that will be required for your target drive, and add it to the total allocated space necessary.

    A better approach would be for you to reformat your target drive to NTFS. Unless you like sticking needles in your eyes, there's not much to be gained by using FAT.
     
  5. Steve Fabian

    Joined:
    May 20, 2008
    Messages:
    3,520
    Likes Received:
    4
    I had written a batch program long ago for calculating file space required for a directory tree based on allocation unit size. It could not take into consideration the size of directory pseudofiles on FAT drives, though it would be possible to do that, assuming a simple directory entry size (i.e., for a file which whose LFN and SFN are the same) of 32 bytes. With some research one could determine the algorithm to determine the space requirement for an LFN based on its length. IIRC the root directory of a FAT drive is limited, and is stored on disk in a special area adjacent to the FAT.

    The problem about reformatting is (at least on my systems) that USB drives (and virtual drives, e.g., SD cards) are usually formatted FAT/VFAT, and there is no program available to reformat them for NTFS (which I would love to do to be able to use junctions, hard links, compressed files and encrypted files). The formatting program incorporated into WinXP does not work on USB drives... I would be glad to hear about sucn a program! It would also be useful to repair bootable hard disk data structures when the drive is removed and installed in an external carrier.
     
  6. Charles Dye

    Charles Dye Super Moderator
    Staff Member

    Joined:
    May 20, 2008
    Messages:
    3,374
    Likes Received:
    40
    Eh? Sure it does; see the /FS: option. You may have to "optimize for performance" first; see e.g. http://www.makeuseof.com/tag/how-to-optimize-usb-drive-with-ntfs/

    I know that you can also do it using DISKPART.EXE in Windows 7; don't know whether that approach works in XP.
     
  7. Steve Fabian

    Joined:
    May 20, 2008
    Messages:
    3,520
    Likes Received:
    4
    Thanks Charles! I'll be using that method very soon!
     
  8. mathewsdw

    Joined:
    May 24, 2010
    Messages:
    855
    Likes Received:
    0
    Thank you, everyone. It would appear that reformatting them to NTFS is the (only really practical!) solution. I knew how to do that (my RAM disk is NTFS, although it's FAT as delivered from the software vendor), I was just reluctant, for some truly unknown reason, to do that to a Flash drive. (After all, the idea of it ever being plugged into a non-Windows NT and its successors machine is virtually nil.)
     

Share This Page