View Single Post
  #21  
Old August 28th 18, 11:22 AM posted to alt.comp.os.windows-10
Paul[_32_]
external usenet poster
 
Posts: 11,873
Default Windows folder excessively large

Ant wrote:
VanguardLH wrote:
MJP wrote:


Run something like sequiaview to give a graphic representation, large
folders/files are easy to distinguish.


I use TreeSize Free. While handy to find the obviously huge files or
folders, they query the file system using standard system file calls.
That means they cannot show you more than what Windows Explorer is
willing to show you (except hidden- and system-attributed files will be
seen by the file size tools rather than hidden as in Windows Explorer).
These tools are useful but not complete.


The problem with those type of utilities is they use the queries from
the file system API to determine file size. You could have a file that
looks like 10KB in size but when you copy or transfer it the actual size
is 10GB. Alternate Data Streams, availble only NTFS, are not accounted
for in a normal file size query.

...

What free utilities can handle that API then?


Streams

https://docs.microsoft.com/en-us/sys...nloads/streams

And NFI should be able to dump info (requires interpretation).
It's possible there is a structure to hold a stream which
is visible in the output of "nfi C: all_fs_info.txt".

https://web.archive.org/web/20150329...us/oem3sr2.zip

The thing is, nfi.exe shows all the cluster LBAs with each
construct in the file system. (You can figure out if a file
is fragmented, by looking at that info.) So it should come pretty
close to showing space consumption. But it still has
"access denied" problems, and things like VSS Shadow copies
in C:\System Volume Information may not be there.

If I need closer to everything, I can use Linux. That
solves my "Access Denied" problem. On a Windows 10 file system,
there could be "I/O error" responses to a run like this.
(Attempts to get info on individual items, ones processed
by CompactOS, may cause a problem.) Here I use the "find"
command on a mounted Win10 volume. Using "df" you can get
the actual name of the mount point and replace the /media/WIN10
strawman in the example. Windows 8 introduced the
Windows Overlay Filesystem, but didn't really use it
that I can see.

find /media/WIN10 -type d -exec ls -al -1 -d {} + ~/directories.txt
find /media/WIN10 -type f -exec ls -al -1 {} + ~/filelist.txt

There really isn't a single tool now (any more),
which is good enough for forensics. It's now a
mess. Thanks, Microsoft.

Think of the good they could do, if they updated
nfi.exe ... You just know they have an internal
utility they're not sharing with us :-)

The output format of nfi.exe needs massaging with
a text processing script, to make the output "useful".
Looking at the text listing will probably make
you curse just a little bit.

A big limitation of nfi.exe, is not showing
all the file pointers on hard-linked files. For
that, if you go to Linux and find two files
with the same "fake" inode number in your listing,
then those are hardlinked together. Or, Sysinternals
offers us this for hardlink dumping. You could
run this hoover style, over your WinSxS directory
and see what pops up in other C:\Windows\System32 areas.

https://docs.microsoft.com/en-us/sys...oads/findlinks

Paul
Ads