Seeing folder sizes for only root folders across multiple devices + changing drive letter of NTFS database

[Herkules97]

So in my continued quest to move to a new device for one of the drive letters, I wanted to be able to sort a new database by size with it having two devices' root folders, under the drive letter so not B: but B:\baba, B:\jo, B:\zer. According to EBV that's depth:1.

First I tried scanning with the folder feature without sub-folders but that only scanned sizes for files directly under each folder.
Later I tried adding the lists for both drives, as I have them both scanned in separate databases, and it looks like sizes exist in .efu but is not being displayed for folders when imported.

I tried the .csv version but that one sucks even more imported to EBV. Maybe I can use something like libreoffice to import the .csv but it would be nice if it could read the data it exports so no other program is needed.

File list editor shows folder sizes and can have two efus loaded in.
But if I want to use the main window, how do I make folder sizes display?

On the same quest..I didn't put the new device as the drive letter I was moving to.
So right now everything I copy to it is copied to H: when it will eventually be swapped and become B:.
I suppose there is no way to alter the database to point to B: without having to re-scan the whole thing? This is with using the NTFS monitoring method.

[therube]

I'm not really clear on what you're after... ?
But if you do similar with, B:\baba, B:\jo, B:\zer...
.

Everything - specific folder sizes, depth 2.png (24.05 KiB) Viewed 8787 times

.

without having to re-scan the whole thing

Re-scanning shouldn't be an issue (particularly) unless you've indexed Properties (which could be potentially slow to gather again).

[Herkules97]

I'm not really clear on what you're after... ?

When you use the main window, you can sort, search and do all that stuff. What I'm looking for is to do that, but with small exports from other databases loaded in. When loading in an .efu, the folder sizes aren't displayed. Everything else works just fine except that.
File list editor is too limited. I can't search, but it also seems like I can't sort by folder names and instead it only sorts full path names.

I wish one could properly import csv. Instead all it has is the filenames, paths and file type stuff. Maybe I'm missing something there.

Re-scanning shouldn't be an issue (particularly) unless you've indexed Properties (which could be potentially slow to gather again).

I don't want to casually re-scan devices unnecessarily. They aren't immortal. Even then I'd still try to use what I've already scanned.
If there is a way to change one letter I should use that instead.

[void]

The folder size is recalculated by Everything and is not loaded from file lists.

While not ideal, one idea is to change the Size header in your EFU file to: Total Size
Total Size is not recalculated.
Load your EFU filelist from File -> Open File List.
Right click the result list column header and check Total Size.

[Herkules97]

The folder size is recalculated by Everything and is not loaded from file lists.

While not ideal, one idea is to change the Size header in your EFU file to: Total Size
Total Size is not recalculated.
Load your EFU filelist from File -> Open File List.
Right click the result list column header and check Total Size.

Adding one device's .efu into the other using Notepad++ did make this work. Shame it doesn't work normally, including using the file list indexing option. Merged and renamed from Size to Total Size instead shows nothing for all items when added back in to the database rather than temporarily loaded in.
At least something reads it in and I don't have to use probably-worse software for this one rare task.

So I take it the answer to the first is to dump any lines like I did to an .efu and load that temporarily, unless in the future you add support for database import to also store folder sizes, the thing in Options - Indexes - File Lists.

And the answer to changing drive letter being that I'll just have to re-scan? I suppose I'm one of the few that likes the index journal.
It's why I didn't keep EBV off scanning the drive as an external with a different drive letter, because then I wouldn't have all the index journal entries of files copied to it and I don't want to swap it out and risk anything before I have made a recent copy of it. Re-scanning 7 million files, a bit more when I'm done copying presumably, seems like the better choice. It's going to read/write a lot like the current B: device so if it can't handle the recent reading and writing, it won't live long and why not get an early sign of that.

But this may have all been for nothing because I realised I'll go through each folder anyway to use Duplicate Cleaner by Digital Volcano to find uniques that aren't in the old full backup of this device. I'll find which folders are too new to have been copied to the backup drive along the way.
At least I know for other times I want to merge .efus and display folder sizes.

Unless you have a better duplicate cleaner program or an accurate way for EBV to find duplicates or uniques.
If I have the RAM I could use NTFS monitoring with exclusions to certain folders, one is 22.9 million files alone, to trim down the needed re-scanning for whatever property(ies) or whathaveyou that would be used and hope I have the necessary RAM for the "Sorting filenames" stage.

I'm sure even if I double the RAM from 64GB to 128GB I'll find more ways to stuff it full. Going from 24GB to 64GB was already a massive boost because I had almost 32GB that I had previously not used, been able to use, for anything. Now I sit at maybe 20GB available at any given point because I run larger and heavier EBV databases at all times
It depends on how many more properties I may want to index. The dream is all, but I tried that and it doesn't seem to handle all well. Tested with a folder, the idea was to see if it's specific properties, specific properties not mixing well with other properties or if it's just not going to work as it takes too long or will never 100% from a property limit or whatever it may be.