Remove Empty Directories

[therube]

I've long thought of an offshoot or enhancement to Everything so that you could use it to (Find &) Remove Empty Directories (RED).

Right now we have the empty: function, & that is fine, but it will only find the "bottom most" empty directory, as it does not consider an empty directory within an empty directory to be empty.

There are a number of RED programs around, but I'm not aware of any that deal directly with the MFT, so usage is much slower.

Maybe something like an emptytree: function, that would find the "top most" empty directory in a tree (& hence all empty child directories too).

Then you could just select them all (or whichever you need) & say DEL.

As it is now, with empty:, you have to run it once, DEL, then run it again, as the second time it will pick up empty parents to the directories you just deleted, which you can then delete, but then you have to run it again because once more it will find empty parents to ...

(And then after that, there could be stuff like ignoring, treating as "empty", files < a size of ## bytes, or 0-byte files, or files named thumbnail.dat ...)

[horst.epp]

And what is the benefit of deleting a few empty dirs deep inside of your trees ?
Empty dirs consume almost no disk space and have no security relevant data.
So its wasting time trying to delete all of them.

[therube]

Because it can be way more then "a few".

Because you may have LOTS of stale empty directory trees that can be pruned (trees, pruned, hmm) so instead of opening Windows Explorer (a file manager actually) & seeing pages full of directory entries, you only see the handful that actually still contain pertinent data.

And while "empty" may not take up much space, other utilities that act on these "empty" directories still need to traverse them... Say even a disk defrag program. It will "defrag", move the directories to where it considers appropriate, but if the were not there at all, then it doesn't even have to consider dealing with them.

(And no I'm not talking a directory here or a directory there, & certainly not a "purposely" empty directory created to "be there", but more along the lines of say you mirror an ftp site or something like that, that over time you've clean up, move or remove files, but the directory trees remain... Or download managers that may maintain the directory structure of the original files source...)


Remove Empty Directories (aka RED)
Empty Folder Nuker
Empty Folder Cleaner
Puran Delete Empty Folders (must be using MFT, but I'm suspect of that one.)

[vfatica]

This is an interesting topic. And while I don't think it's Everything's place to modify the file system, I can't even get off the ground.
If I simply enter "empty:" (no quotes) in the Everything search string location, many of the folders listed are not empty. I've tried to attach a link (FTP) to an image; I don't know if that will work.

[img]ftp:%20//lucky.syr.edu/empty.png[/img]

Here it is in plain text: ftp: //lucky.syr.edu/empty.png

The only thing I can find in common among what Everything does return is that they all have no subfolders.

Try almost anything in the \Windows\winsxs tree which is reported by "empty:".

- Vince

[therube]

It appears to have to do with hard links.
At the least, one of a pair (or more ?) of directories containing (only) hard links is considered "empty".

To me, that behavior is wrong.


(I would typically NOT use [any] empty directory remover within anything "Windows". [And virtually everything in Win7 & up dealing with "Windows" are hard links.])

[therube]

Yes, that's what it is doing.

readme.TXT in C: & readme.TXT in both X & Y are hard links of one another.
readme.TXT in 7 is not.

empty: considers X & Y to be "empty".
IMO it should not.

Code: Select all

C:.
|   readme.TXT
|   
+---7
|       2
|       chrome.manifest
|       GPL.txt
|       install.js
|       install.rdf
|       readme.TXT
|       
+---x
|       readme.TXT
|       
\---y
        readme.TXT

[therube]

Also note that empty: does not "directory monitor".

IOW if something in a directory has changed once empty: has been "run", those change are not seen (monitored) by empty:.

You would have to "refresh" the empty: command for changes to be "seen".


The same empty: command, from above:
> while Everything is still showing empty:
Create a file "123" & copy it into the directory X [above]

> view the Everything window
> Everything still shows that the directory X as empty, when it no longer is

> now change the search term in Everything, say, empty: abc
> and revert that change back to simply, empty:

At this point, & only at this point, the directory X is no longer seen as "empty" & so no longer displays as/with empty:.

[vfatica]

It appears to have to do with hard links.
At the least, one of a pair (or more ?) of directories containing (only) hard links is considered "empty".

To me, that behavior is wrong.

We agree.

(I would typically NOT use [any] empty directory remover within anything "Windows". [And virtually everything in Win7 & up dealing with "Windows" are hard links.])

You can reliably tell if a directory is empty, but right now, not with Everything.

[void]

empty: will find folders that are empty in the Everything index.
They may not actually be empty on disk.

This may occur if you exclude files, or as therube mentioned if they contain hardlinks.

Please confirm folders are empty with File -> Properties (Alt + Enter) before deleting them.

With hard link support in the next release this should be less of an issue.

[therube]

You can reliably tell if a directory is empty, but right now, not with Everything.

I would think it is less of a matter of whether you can or can't reliably tell, rather a matter that even if it is "empty" (meaning empty with only hard links inside, or even really empty), it is a directory that Windows itself expects to be seen to be there to be available, even if "empty".

[vfatica]

You can reliably tell if a directory is empty, but right now, not with Everything.

I would think it is less of a matter of whether you can or can't reliably tell, rather a matter that even if it is "empty" (meaning empty with only hard links inside, or even really empty), it is a directory that Windows itself expects to be seen to be there to be available, even if "empty".

Are we mincing words? There's NO difference between a directory containing a file and a directory containing a hard link.

If (for example) I

Code: Select all

g:\z1> echo Hello world! > greeting.txt

I have created a file object, known by its index number

Code: Select all

g:\z1> echo %@inode[g:\z1\greeting.txt]
00100000:000004A3

and a hard link to that object is put in the directory entry for "g:\z1".
If I then create (another) hard link to the same object

Code: Select all

g:\z2> mklink /h greeting.txt g:\z1\greeting.txt
Hardlink created for greeting.txt <<===>> g:\z1\greeting.txt

g:\z2> echo %@inode[g:\z2\greeting.txt]
00100000:000004A3

the only thing that happens is that a hard link to the (one) file object is (also) put in the directory entry for "g:\z2".

Now the same object has a hard link in two directories. Neither is special in any sense. The file itself is deleted when the last of its hard links is deleted.

[therube]

> Are we mincing words?

No, I'm just saying (IMO) that arbitrarily deleting "empty" windows (OS) directories (be they truly empty or only contain links) may not be the safest thing to do, because windows may rely on their existence - even if empty.

(Likewise for "duplicate file finder [& deletion]" type programs.)

And given the way that empty: currently works, it is even more dangerous to use in "\Windows" (aka Windows OS created "system" directories).

Now, something of your own creation, say your "Music" directory that you know what's been done there, that you know there aren't any links, there shouldn't be any issues with empty: & that. (And even with that, instead of outright deletion, it would be safer to move the empty directories to specified directory, where you can confirm that in fact they are empty. [Like Properties of that directory showing a size of 0-bytes.])


> The file itself is deleted when the last of its hard links is deleted.

Sure.

[vfatica]

I'm just objecting to "containing only links". It is absolutely nothing special (except to Everything). A directory **IS** a list of links. All directories "contain only links". Hard links are bi-directional. If file2 is a hard link to file1 then, by definition, file1 is a hard link to file2.

Examples using the win32 API function FindFirstFileNameW() (which (MS Docs) "Creates an enumeration of all the hard links to the specified file"),

Code: Select all

v:\> linksto c:\Windows\explorer.exe
C:\Windows\winsxs\x86_microsoft-windows-explorer_31bf3856ad364e35_6.1.7601.17514_none_53bc10fdd7fe87ca\explorer.exe
C:\Windows\explorer.exe

v:\> linksto C:\Windows\winsxs\x86_microsoft-windows-explorer_31bf3856ad364e35_6.1.7601.17514_none_53bc10fdd7fe87ca\explorer.exe
C:\Windows\winsxs\x86_microsoft-windows-explorer_31bf3856ad364e35_6.1.7601.17514_none_53bc10fdd7fe87ca\explorer.exe
C:\Windows\explorer.exe

v:\> echo Hi! > file1

v:\> mklink /h file2 file1
Hardlink created for file2 <<===>> file1

v:\> linksto file1
v:\file1
v:\file2

v:\> linksto file2
v:\file1
v:\file2

[therube]

Everything 1.4 has a new function, childfoldercount:, & if you combine that with size:, that can be used to find empty directories that may also happen to contain 0-byte sized files.

So something like:

> childfoldercount:0 size:0

Will find bottom-most empty directories - even if they contain 0-byte files within.

So this behavior is a little bit different from the empty: function.
(Using childfoldercount: + size: can find more "empty directories" then empty: alone, if you want to consider 0-byte files in a directory to be "empty".)

LIkewise, you can adjust size: if you wanted to expand your definition of "empty".

> childfoldercount:0 size:<100

So that would find bottom-most empty directories, or bottom-most empty directories that may contain file of 99 bytes or less.

[therube]

childfoldercount:0 size:0

Could someone tell me how I did that, as I can't seem to get any results returned now when I include the size:0 ?

Oh, it's going to require that you 'Index folder size' too!
(See, sometimes it helps to write things out .)

[therube]

So thinking about this a bit...

childfoldercount:0 size:0

A slight change: childfoldercount:>0 size:0

And then even more if you wish, with parents:

So if your starting directory is:

> C:\TMPS\3

childfoldercount:0 size:0 parents:3

And a slight change again:

H:\TMPS\3 childfoldercount:>=0 size:0 parents:3

Will find topmost empty directories .

Code: Select all

H:\TMPS\3\2.empty
H:\TMPS\3\99.empty

Code: Select all

H:.
+---1.not.empty
|       xxx
|       
+---2.empty
+---3.not.empty
|   |   xxx
|   |   
|   +---3.1
|   +---3.2
|   \---3.3
\---99.empty
    +---99.1
    |   \---99.1.2
    +---99.2
    |   +---99.2.1
    |   \---99.2.2
    \---99.3
        +---99.3.1
        |   \---99.3.1.2
        |       \---99.3.1.2.3
        +---99.3.2
        \---99.3.3

I believe this is working as I expect it to.
That said, experiment carefully.


Just pruned a directory tree of 743 (topmost) empty directories (& an untold number of child directories therein ).
(Amazing how junk can pile up - in both digital & real forms .)