Not seeing items / real names in Recycle Bin and experiencing filtering drawbacks

[Thy Grand Voidinesss]

Steps to reproduce:

#1] I create file

test.txt

on volume C and P

#2] I see them on the list in main window of Everything as

test.txt

in both the Column of Name and of Display Name

#3] I delete them

#4] I now see them as gibberish

$IS8XDTA.txt

and

$IH77PO4.txt

in my Column of Name and still as

test.txt

in the Column of Display Name

#5] After writing in the Search Edit box e.g.

test.txt

or

test .txt

they are not shown on the list with now filtered down results

#6] After switching to a Filter set up beforehand with such options

Code: Select all

Search: :\$recycle.bin\ !$I <search: | displayname:search:> columns:dm;property-system:system.recycle.datedeleted;extension;size;length;path;displayname;type;name;
Macro: bin<search>

I see them back on the list i.e. with Search Edit box still having in it e.g.

test.txt

or

test .txt

[or any other appropriate filtering expression]


So my question is: how am I suppose to know that a file named

test.txt

is or is not present on my indexed drives without a need of using a Filter with the above settings? Should not the default Filter named Everything be able to show it in case when it has been moved to the Recycle Bin?

I have Column of Display Name turned on and it shows me

test.txt

in that Column when this file no matter if it is residing in some folder or in the Recycle Bin - but when I try to filter it out using the basic Search Edit feature it disappears until I add to it another layer in form of more advanced search feature of Filter. Where is the logic in this? Or am I just experiencing some bug?


I am using Everything 1.5.0.1356a x64 Portable on Windows 10 Enterprise 20H2 x64

[void]

This is expected.

Everything shows the true filenames as they are on disk.

Filenames in the $recycle.bin folder are:
$r... for the original data.
$i... for the original filename information.

The recycle bin you see in Windows Explorer is a virtual folder.
(not a real folder on disk)



If you would like to search the recycle bin for the original filename, please try the following search:

\$recycle.bin displayname:"test.txt"

display-name:



To add the virtual recycle bin folder to your index:

• In Everything 1.5, from the Tools menu, click Options.
• Click the Folders tab on the left.
• Click Add Custom....
• Change the Path to: Recycle Bin
• Click OK.
• Click OK.

[Thy Grand Voidinesss]

This is expected.
[...]

Could not there be a setting somewhere in Options, that would make Everything always look for [if I understood the whole shebang correctly] the Display Name? I myself even when searching intentionally within Recycle Bin do it 99.999% of the time with intention of looking for and finding the normal name and not its Recycle Bin's coded equivalent

If you would like to search the recycle bin for the original filename, please try the following search:

\$recycle.bin displayname:"test.txt"
[...]

This works- but it is even more inconvenient than having to remember that I need to use that Filter of mine

To add the virtual recycle bin folder to your index:
[...]

This changes nothing- i.e. I still am forced to use that Filter after deleting an item in order to see it on the list


All in all, in my opinion, user should not be burdened with having to remember about this dichotomy and thus be required to use special ways of finding items just because they happen to reside in the Recycle Bin. Those extra steps should only be reserved for a case when user is looking specifically in e.g.

P:\$RECYCLE.BIN

and not when just looking everywhere [i.e. using the default Filter of Everything]

[void]

No filter should be required when indexing the virtual recycle bin folder.

Searching for:

test.txt

should show the following result:

Recycle Bin\test.txt

[therube]

Ah, the pertinent part which you nor I picked up on, at first:

Click Add Custom....

So not "Add...", but rather "Add Custom...", & with that, "test" will find "test" in "recycle bin/".


Mouseover on Add Custom... says, "Add a virtual folder or path with an environmental variable.".
(I didn't realize that either.)

[Thy Grand Voidinesss]

No filter should be required when indexing the virtual recycle bin folder.
[...]

Yes, that is correct

Just please reconsider how the Recycle Bin is being handled by default, i.e. when user is not utilizing a Filter for it and / or indexing it as an also manually added Folder

[Thy Grand Voidinesss]

This has stopped working for me


Under the

Tools > Options > Indexes > Folders

I still have

Code: Select all

Recycle Bin

added - and yet whatever I delete something it disappears from the list in main window, until I switch

[...]
to a Filter set up beforehand with such options

Code: Select all

Search: :\$recycle.bin\ !$I <search: | displayname:search:> columns:dm;property-system:system.recycle.datedeleted;extension;size;length;path;displayname;type;name;
Macro: bin<search>

[...]

Currently I am using Everything 1.5.0.1366a MOD1 x64 Portable

[Thy Grand Voidinesss]

[And this issue has apparently nothing to do with this one viewtopic.php?t=13224 because for the moment being indexing of my volume C works A-OK]

[Thy Grand Voidinesss]

I have made some new observations


A] When using that Filter of mine I delete multiple instances of such files from various volumes

Code: Select all

test.txt
test.txt.txt

and enter in the box of Search Edit

Code: Select all

test.txt

then I will be shown both of those files originating from multiple volumes [i.e. multiple instances of them, each correctly with a different Path]


B] When using that Filter of mine I delete multiple instances of such file from various volumes

Code: Select all

test file.txt

and enter in the box of Search Edit

Code: Select all

test file.txt

then I will be shown nothing. But if I put it in quotes i.e. search for

Code: Select all

"test file.txt"

I will be shown this file originating from multiple volumes [i.e. multiple instances of it, each correctly with a different Path]


C] When not using that Filter of mine [i.e. intending to see everything] I delete multiple instances of such files from various volumes

Code: Select all

test.txt
test.txt.txt
test file.txt

and enter in the box of Search Edit whatever combination I only get to see incorrectly always one instance of each, with their Path being described as

Recycle Bin

So apparently this

This has stopped working for me


Under the

Tools > Options > Indexes > Folders

I still have

Code: Select all

Recycle Bin

added - and yet whatever I delete something it disappears from the list in main window, until I switch

[...]
to a Filter set up beforehand with such options

Code: Select all

Search: :\$recycle.bin\ !$I <search: | displayname:search:> columns:dm;property-system:system.recycle.datedeleted;extension;size;length;path;displayname;type;name;
Macro: bin<search>

[...]

Currently I am using Everything 1.5.0.1366a MOD1 x64 Portable

has been fixed as currently I am using version 1.5.0.1367a - but not fixed up entirely


D] A somewhat stand-alone Recycle Bin issue: viewtopic.php?p=64517

[void]

Please change your filter search to:

Code: Select all

:\$recycle.bin\ !$I <<search:> | displayname:<search:>> columns:dm;property-system:system.recycle.datedeleted;extension;size;path;length;displayname;system.recycle.deletedfrom;name;type

You will need to wrap search: inside < and > to pass all the search terms to displayname:

[horst.epp]

Please change your filter search to:

Code: Select all

:\$recycle.bin\ !$I <<search:> | displayname:<search:>> columns:dm;property-system:system.recycle.datedeleted;extension;size;path;length;displayname;system.recycle.deletedfrom;name;type

This search doesn't show any results for me.
Recycle.bin definitely contains files.
______________________________________________________
Windows 11 Home x64 Version 23H2 (OS Build 22631.3085)
Everything 1.5.0.1366a (x64), Everything Toolbar 1.3.2

[NotNull]

This can't be used directly in the search bar as this is a filter definition:

Name = Mühlkorb (or whatever you like)
Search =

Code: Select all

:\$recycle.bin\ !$I <<search:> | displayname:<search:>> columns:dm;property-system:system.recycle.datedeleted;extension;size;path;length;displayname;system.recycle.deletedfrom;name;type

Macro = <search>


Or:
Name = Mühlkorb (or whatever you like)
Search =

Code: Select all

:\$recycle.bin\ !$I <<$param:> | displayname:<$param:>> columns:dm;property-system:system.recycle.datedeleted;extension;size;path;length;displayname;system.recycle.deletedfrom;name;type

Macro = (leave empty)

[horst.epp]

This can't be used directly in the search bar as this is a filter definition:

Thanks, understand it now.
I made a filter with macro name wb and a bookmark which refers to it.
The filter columns can be much shorter for me, it's now:

Code: Select all

:\$recycle.bin\ !$I <<$param:> | displayname:<$param:>> columns:displayname;system.recycle.deletedfrom;dm;size;property-system:system.recycle.datedeleted

[Thy Grand Voidinesss]

Using this

[...]

Code: Select all

:\$recycle.bin\ !$I <<search:> | displayname:<search:>> columns:dm;property-system:system.recycle.datedeleted;extension;size;path;length;displayname;system.recycle.deletedfrom;name;type

[...]

as my new Search expression in that Filter for mine dealt with reported in this post viewtopic.php?p=64519#p64519] the A-B issue of having to use quotes [which I no longer have to do]; so thank you for upgrading that code


But the issue C [and partially D] from that post are still relevant

And also the problem from post viewtopic.php?p=64107#p64107 is still relevant - i.e.my initial issue of not seeing an item that is deleted when using the default Everything [no]Filter is back, despite me still having Recycle Bin folder added to

Tools > Options > Indexes > Folders

[Thy Grand Voidinesss]

To re-cap:

I] My Recycle Bin is added at

Tools > Indexes > Folders

with the option

Attempt to monitor changes

being selected


II] Among my Filters I have a special one performing searches in Recycle Bin with such settings

Code: Select all

Search
:\$recycle.bin\ !$I <<search:> | displayname:<search:> | original-location:<search:>> columns:dm;date-deleted;extension;size;path;length;displayname;original-location;name;type

Macro
bin<search>

III] My current version of Everything is 1.5.0.1396a x64 Portable



And the only remaining issue is this:

When I delete from various volumes files that have identical name, I see all of them only if I switch to using that Recycle Bin oriented Filter. Because if use use the default "Filter" [named Everything] I only see one instance of them and the

Path

Column describes them as being in Recycle Bin

[void]

And the only remaining issue is this:

When I delete from various volumes files that have identical name, I see all of them only if I switch to using that Recycle Bin oriented Filter. Because if use use the default "Filter" [named Everything] I only see one instance of them

This is expected.

Everything is a filename search engine.
Everything shows the real filenames as they are on disk, not what you see in Windows Explorer under the virtual Recycle Bin folder.

When you delete a file/folder it is given a random $rxxxxxx name.

Use your bin filter to show the display name column.
The display name is the name you'll see in the virtual Recycle Bin folder.

[Thy Grand Voidinesss]

But I still do not understand why the default filter "Everything" will show just 1 instance of e.g.

deletion test.txt

when I will look for it despite having deleted it 3 times from 3 different volumes - while at the same time when via FreeCommander or Windows Explorer when I open the Recycle Bin overall system folder [not a particular Recycle Bin folder from a given volume] I see all 3 such named files that have been deleted?

Why cannot Everything, without using a specialized Filter, also show all of them but merely reveals a confusing stand-in? For me logical would be to show either 3 because 3 were deleted or 0 because none are available outside the Recycle Bin - because showing just 1 is simply misleading

[therube]

Because if use use the default "Filter" [named Everything] I only see one instance of them and the

Path

Column describes them as being in Recycle Bin

When you delete a file, it is given a "guid".
When you delete a directory, the directory is given a "guid", but the files within retain their original names.

So I'm thinking that if <Everything filter> finds the item, & the item path is in $Recycle.Bin, then that item resides within a subdirectory of $Recycle.Bin, & so has retained its' original name (instead of having a guid).


Other possibility could be that "$Recycle.Bin" has lost its significance. I.e., it is a directory that happens to be named "$Recycle.Bin", but is not an actual (system) $Recycle.Bin. (Like if you copied an actual $Recycle.Bin directory to somewhere else, that copy may be named, but is not an actually $Recycle.Bin.)

[void]

Everything will show the deleted file, but it will not be shown as

deletion test.txt

When you delete

deletion test.txt

it will be moved to your recycle bin folder and renamed to

$rxxxxxx.txt

where xxxxxx is a random string.

-If

deletion test.txt

is in a folder and you delete the folder, the folder is instead renamed to

$rxxxxxx

deletion test.txt

is left untouched.



To see what is happening when you delete a file:
In Everything, from the Index menu, click Index Journal.
Change the Index Journal Search to:

*.txt

Create a new text document on your desktop.
Delete the new text document.txt
View the file system changes in the index journal.

[Thy Grand Voidinesss]

In Everything 1.5.0.1400a x64 Portable on my Windows 10 Enterprise 20H2 x64 [10.0.19042] when I delete solely a file [i.e. not delete a folder in which that file happens to reside] and then navigate in FreeCommander to a Recycle Bin like e.g.

M:\$RECYCLE.BIN\S-1-5-21-3797103458-798797042-3558267449-1001

name of that file is shown renamed to a coded gibberish. But when I evoke in that program the overall Recycle Bin

::{645FF040-5081-101B-9F08-00AA002F954E}

then I see its original normal name. But in Windows Explorer I always see its original name, even if I paste in to its bar the same path

M:\$RECYCLE.BIN\S-1-5-21-3797103458-798797042-3558267449-1001

because apparently Windows Explorer always shows to me content of all Recycle Bin folders i.e. I cannot narrow down presented list of items to just one Recycle Bin folder from a particular volume


So... so far so good - i.e. Everything program is not responsible for different behavior by 2 different file explorers. But here comes the bug and / or lack of logic within Everything:


Because what happens if I delete 1st file? It disappears from the main list seen when Filter named Everything is active. And in order to see that deleted file I need to use that Recycle Bin oriented Filter of mine. So still so far so good

But what happens if I switch back to using the Everything Filter and delete 2nd file with exact same name? It also correctly disappears from the list - and refreshing the view does not change what I [do not] see. So now I once again need to switch to using such proper custom made Filter that allows me to see this second [and first] deleted file

But now if I will again switch back to using the Everything Filter, then an entry with that name appears on the list with a location specified as

Recycle Bin

So why those deleted files do not start to appear from the get-go [i.e. after first deletion] but only after second deletion and additionally after me having used Recycle Bin oriented Filter and then also switching back to using the default Filter? And why am I only shown 1 entry on the list [when using now the default Filter], when it represent 2 files from 2 different [source / Original] locations? How is a user suppose to know that this 1 entry represent 2 and not 1 or 3 files? Right now this entry when it shows up is an opaque umbrella hiding whatever amount of files


As for the scenario when files [bearing the same name] get deleted by the means of deletion of folders in which they reside [also sharing a same name but different from the name of files], handling of their naming in FreeCommander and Windows Explorer behaves the same as above i.e. FC shows gibberish within a Recycle Bin folder but normal name withing the system wide Recycle Bin folder, while WE always shows normal name. And the same is true for name of folder

But the appearance in Everything of file deleted in such way and appearance of its folder is not the same like in case of deletion of directly / solely file. Because although its presence on the list when using the Everything Filter needs to be triggered with switching to that custom Filter - it nevertheless does not require a companion file / folder bearing the exact such name i.e. a deletion of second one is not needed

But there are additional issues: after deletion the file shows no data in the Date Deleted column, while its folder does; and also the file shows no data in the Original Location column. I reckon it is not a bug but a feature, due to technically this being logical because the file was not deleted - it was the folder holding that file that got deleted. But then again: how is a user suppose to know that it is not some bug manifesting itself with lack of shown data? An intended lack of data and erroneous lack of data look the same, amiright? And what is more, when I switch back to the Everything Filter then the Path of that deleted folder is shown as

Recycle Bin

but the Path of file it was holding is shown as

M:\$RECYCLE.BIN\S-1-5-21-3797103458-798797042-3558267449-1001\$RFEXXYR

In my opinion this file is shown in an informative way, because colu,m of Path includes the name that this file now has when it is in this local Recycle Bin folder - but at the same time it reveals no connection to Path of its folder it was residing in before deletion of that folder. But then again: how could the deleted folder show a Path of a local Recycle Bin when more than 1 folder bearing the same name got deleted and Everything shows only 1 entry when using the default Everything Filter i.e. how would it pick which source / original location to show?


I know that this report and my reasoning got a bit complicated and way too long, but it all comes down to this: presence of deleted items on lists in Everything is inconsistent, they are displayed with ambiguous info or lack of thereof, plus they might require triggers in form to switching back and forth between Filters in order to show up at all

[void]

You are indexing the virtual folder:

Recycle Bin

This folder is very slow to update in Everything if you don't have a Windows Explorer window opened and browsing the recycle bin.
-A updatedir event is only generated if a Windows Explorer window is opened and browsing the recycle bin.
-This is a limitation with the shell.

Everything also doesn't allow duplicated filenames.
So

Recycle Bin\deletion test.txt

can only exist once in Everything, while Windows Explorer will show duplicates.

I don't recommend indexing the virtual folder

Recycle Bin

.
Everything is designed to index real file systems.

[Thy Grand Voidinesss]

You are indexing the virtual folder:

Recycle Bin

This folder is very slow to update in Everything if you don't have a Windows Explorer window opened and browsing the recycle bin.
-A updatedir event is only generated if a Windows Explorer window is opened and browsing the recycle bin.
-This is a limitation with the shell.

Would using a script which would open a hidden Windows Explorer instance "exploring" for user that system folder do the trick? I could try to write one that would either monitor for already opened Recycle Bin and act upon lack of thereof or just add one-time opening to my master script that adjusts system after logon

Everything also doesn't allow duplicated filenames.
So

Recycle Bin\deletion test.txt

can only exist once in Everything, while Windows Explorer will show duplicates.

You mean it does not allow in the Recycle Bin, right? Because I have gazillion of duplicates due to having dozens of various backups done with the timestamp fashion

Could not this be solved / worked around by adding to Everything some mandatory internal counter of files with the same name? With an ability to (non mandatory) display that counter in a column?

I don't recommend indexing the virtual folder

Recycle Bin

.
Everything is designed to index real file systems.

Then it is a real bummer if a program named Everything is unable to index everything. I understand it not being able to deal with an niche / edge case like this one viewtopic.php?t=17290 - but the Recycle Bin is a vital part of the system that goes back to Windows 95. I personally often seek for something within it for retrieval and usually (because storage is cheap while cost of loosing data is always to high) I have tens of thousands of items in it - thus not being able to have instantly presented search result break the workflow

[Herkules97]

but the Recycle Bin is a vital part of the system that goes back to Windows 95. I personally often seek for something within it for retrieval and usually (because storage is cheap while cost of loosing data is always to high) I have tens of thousands of items in it - thus not being able to have instantly presented search result break the workflow

If you want to search normally, stop dumping stuff in that silly "folder"...Maybe get better at knowing what you want to delete? If you only shift+delete what you want gone, you won't have to bother with the bin at all.
If you are somehow unsure of deleting something there are other ways of tallying them. Export anything as efu to a folder somewhere, maybe also then index all the .efus in that folder to an instance. Bam, you can now see all files in one result list that you may want to delete in the future.

You can also open each efu individually and if you end up deleting something, remove the efu from the folder to know it's been completed.
All efus in one lists would be for searching all efus, but for deleting loading only one efu at a time might be better. This can be done in the same instance.

Other way is to move stuff to a particular folder. This would mean if files are on a different storage device they would first be copied. That seems highly unnecessary given you might want to move files worth 1GB+.
But you could get a cheap SSD that is used only for this purpose or similar temp operations.

Another method could be autohotkey, a script that would move files when you press delete. Either to still a specific folder on only one device or AHK may be able to be scripted to move files on the same device to a particular folder. Like Device1\Maybe-delete and Device2\Maybe-delete. This would nullify the need to copy anything.
I only bind simple stuff like arrow keys to wasd so I don't know how to do such a thing if it's even possible.
I know this would mean that only one name can be used per folder/file and duplicates could replace unless auto-renaming can be scripted and secondarily the original path would no longer be known. But Idk why you aren't deleting stuff if you are sure and if not sure just letting it be. That's how I do it and it works fine.

Maybe there are third-party programs that replace the bin? I've never cared about the bin to the point I've looked for that.

[void]

Would using a script which would open a hidden Windows Explorer instance "exploring" for user that system folder do the trick? I could try to write one that would either monitor for already opened Recycle Bin and act upon lack of thereof or just add one-time opening to my master script that adjusts system after logon.

Have your script periodically call SHChangeNotify with SHCNE_UPDATEDIR and with the virtual recycle bin folder.
-or-
Have Everything rescan your virtual recycle bin folder periodically under Tools -> Options -> Folders -> Recycle Bin -> Rescan every x minutes.

You mean it does not allow in the Recycle Bin, right? Because I have gazillion of duplicates due to having dozens of various backups done with the timestamp fashion

Everything doesn't allow duplicate filenames in the same "index".
The "index" being your folder index of the virtual recycle bin folder.
This is a hard limitation with Everything.

Then it is a real bummer if a program named Everything is unable to index everything.

Sorry, Everything cannot do everything.
Everything is designed to index real file systems, not large virtual file systems.
Virtual file system indexing support was added to index small file systems on phones.
The real recycle bin is still indexed, but the filenames are mangled.
The mangling is done so you can have duplicated filenames in the virtual recycle bin.

Index the real recycle bin under C:\$recycle.bin, which is normally done by default.
Use the

displayname:

search function with

:\$recycle.bin\ !$i*

to search your recycle bin for specific filenames.
Show the Display Name column to view the original filenames in the real recycle bin folder.
Avoid indexing Display Name.

[Herkules97]

Avoid indexing Display Name.

However as someone that indexes recycle bins with display name property, it seems to work just fine.
Don't need to use your existing instances to do it, I have one specifically for recycle bins. A folder-indexed one.
This does mean it doesn't know what volume a file belongs to so it doesn't know what files are offline.
But recycle bin rng names are also in NTFS instances I believe, so you can..cross-reference? to find what files belong to what.
For example copying the file paths to the names from the NTFS instance, then inputting the search in the bin instance.

I think maybe recycle bins can fail to be found by Windows if you have a new system install? If so that's another reason to avoid these bins. They obfuscate and may have tedious behaviours like that.

I was able to archive one of the folders I found using 7-Zip. Though it archives with the bin names so you'll have to index display name with EBV and rename them manually..Or there is a better way out there like fixing so Windows can read the stupid things.
I am interested in this myself as I have at least 3GB sitting in bins with files I can't access in the bin window. So I can't see original file paths and such.

I recently bothered checking and it turns out EBV doesn't have anything in date removed nor original file path. Those columns are empty for the Windows Property System ones and EBV's ones. Maybe there is a third-party tool that can read these bins properly..
Fortunately most older HDDs I have, I've copied with Robocopy.
Comparing one old HDD it seems this means it's copied its bins.
I never indexed that old HDD's recycle bins and the copied version isn't giving the original filename.

I decided to not be lazy and find a way to read the data myself.
https://abelcheung.github.io/rifiuti2/
This program can read the data that EBV can't.
This applies to the robocopied version as well, I don't know if all robocopied versions work fine but at least the one I found does.
You can make an exported file with all recycle bins you can find.
This reads like it can only read the data, it can't extract the files. So this way you'd still have to archive with 7-Zip and manually rename.
But at least you can get the files and the names and maybe one day rename them all.
Or presume everything was meant to be deleted and empty the folders.