Note, also, that the total size of the files will be less than the total size they take on disk. Because of the way FAT and NTFS allocate large blocks of the disk, a bunch of small files will take up a lot more space on the disk than you may imagine.
Of course, there's a VFP function to tell you cluster size, too. Check out SYS(2022), but read the caution in the Hacker's Guide, as the function isn't always accurate.
On Wed, Aug 3, 2016 at 1:18 PM, Fernando D. Bozzo fdbozzo@gmail.com wrote:
Yes, it totalizes every file that encounters traversing all subdirs. May be an "H" must be added to the "D" for hidden files, I didn't tested with them totally.
The OS haven't a command for this, that's why when you right-click/properties a folder, you can see that in this moment the disk reads a lot, because it's doing the same.
2016-08-03 18:33 GMT+02:00 Stephen Russell srussell705@gmail.com:
Does this walk the folder tree and pull the sizes from en-US, etc, SEP, and on and on... totaling all of the sizes combined?
I am guessing that there is no api that does this in Win7 at least. From the explorer I click for Properties of a BIG folder and it takes a few secs to total up all the content. You see it flashing as it updates.
Case in point C:\Windows 46.1 gig for me. YMMV
On Wed, Aug 3, 2016 at 8:21 AM, Fernando D. Bozzo fdbozzo@gmail.com wrote:
Another solution pure VFP here:
? get_DirSize("c:\Windows\System32\drivers")
PROCEDURE get_DirSize LPARAMETERS tcDir EXTERNAL ARRAY taFiles LOCAL laFiles(1), I, lnFiles
IF VARTYPE(pnDirSize) <> "N" PRIVATE pnDirSize pnDirSize = 0 ENDIF tcDir = ADDBS(tcDir) lnFiles = ADIR( laFiles, tcDir + '*.*', 'D', 1) FOR I = 1 TO lnFiles && Look for files IF NOT SUBSTR( laFiles(I,5), 5, 1 ) == 'D' pnDirSize = pnDirSize + laFiles(I,2) ENDIF ENDFOR FOR I = 1 TO lnFiles && Look for Subdirs IF SUBSTR( laFiles(I,5), 5, 1 ) == 'D' AND NOTINLIST(laFiles(I,1),
'.', '..') get_DirSize( tcDir + laFiles(I,1) ) ENDIF ENDFOR
RETURN pnDirSizeENDPROC
2016-08-03 13:43 GMT+02:00 Laurie Alvey trukker41@gmail.com:
You can also use filer.dll like this:
LOCAL oFiler As CFileUtil OF Filer.FileUtil LOCAL i, n, c, o CREATE CURSOR files (fullname V(50), attrib I, bytes I) oFiler = NEWOBJECT("Filer.FileUtil") oFiler.SearchPath = GETDIR() IF EMPTY(oFiler.SearchPath) RETURN ENDIF oFiler.SubFolder = 1 oFiler.FileExpression = "*.*" oFiler.Find(0) n = oFiler.Files.Count IF n > 0 CLEAR FOR i = 1 TO n o = oFiler.Files.Item(i) c = o.Path + o.Name INSERT INTO files VALUES (c, o.Attr, o.Size) ENDFOR ENDIF SUM bytes TO n ? "Total size", CAST(n As B(0))
Laurie
On 2 August 2016 at 12:46, Stephen Russell srussell705@gmail.com
wrote:
Have used this in C# a long time ago.
long length =
Directory.GetFiles(directoryPath,"*",SearchOption.AllDirectories).Sum(t
=> (new FileInfo(t).Length));
On Tue, Aug 2, 2016 at 12:58 AM, Fernando D. Bozzo <
fdbozzo@gmail.com>
wrote:
Yeah, I know, but I tend to find optimization and speed. It's the same as using "select * into cursor" just for looking the
_tally
El 2/8/2016 7:40, "Gérard LOCHON" g-lochon@wanadoo.fr escribió:
> Generally, it's multipurpose > > > Le 02/08/2016 à 00:56, Fernando D. Bozzo a écrit : > >> I think that creating a cursor and is too much for something
that
only
>> need >> to sum file lenghts. >> Can be done with 2 arrays, one needed for ADIR and one for
keeping
the
>> paths and subtotals. >> >> >
[excessive quoting removed by server]