"Empty recycle bin"-feature erased all files on a Partition

[Switch]

An example, I have a file on a NTFS-nonsystem-partition called "D:\Folder\File.txt".
Bb showed in the livelog it's deleting something like "D:\$RECYCLE.BIN\Folder\File.txt", which obviously does not exist, but it deleted "D:\Folder\File.txt" in reality.

So that's what bleachbit does with the whole freaking partition (3TB of data).

I killed the process after 700GB of Data were already deleted. It was a massive pain and 2% of my data was not restorable anymore, but that's another topic.

Let me know if I can do anything for you to figure this out.

BB Version: 1.17
OS: Windows 10 Pro 64-bit / 1709 / 16299.64

[Andrew Ziem (ahziem1)]

Thank you for the bug report, Switch.

Was drive D: a fixed or removable drive? Were the files deleted using Windows 10?

I tested the latest BleachBit version (similar to version 1.17 that you have) on Microsoft Windows 10.0.16299.125. I created a second fixed drive (2GB) with NTFS partition. On that drive I deleted one whole folder with >100 objects (files and folders), and then I ran a preview in BleachBit.

It showed lines that looked like below. Is this like what you saw?

Delete 5.2kB G:\$RECYCLE.BIN\S-1-5-21-259089694-2264239342-2853358479-1001\$RD84L6V\etc\fonts\fonts.conf
Delete 7kB G:\$RECYCLE.BIN\S-1-5-21-259089694-2264239342-2853358479-1001\$RD84L6V\etc\fonts\fonts.dtd
Delete 724B G:\$RECYCLE.BIN\S-1-5-21-259089694-2264239342-2853358479-1001\$RD84L6V\etc\gtk-2.0\gtk.immodules
Delete 241B G:\$RECYCLE.BIN\S-1-5-21-259089694-2264239342-2853358479-1001\$RD84L6V\etc\gtk-2.0\gtkrc
Delete 890B G:\$RECYCLE.BIN\S-1-5-21-259089694-2264239342-2853358479-1001\$RD84L6V\etc\gtk-2.0\im-multipress.conf
Delete 736B G:\$RECYCLE.BIN\S-1-5-21-259089694-2264239342-2853358479-1001\$RD84L6V\etc\pango\pango.aliases
Delete 160B G:\$RECYCLE.BIN\S-1-5-21-259089694-2264239342-2853358479-1001\$RD84L6V\etc\pango\pango.modules

In my case these were the correct files. The long prefix "G:\$RECYCLE.BIN\S-1-5-21-259089694-2264239342-2853358479-1001\$RD84L6V" was added by Windows because this is a special folder.

Let me know.

[Switch (switch-2)]

Hi Andrew, tanks for your reply.
Drive D: is a fixed drive (GPT & NTFS & no RAID)

About the Path, I'm not really sure anymore because the bb log was empty after I killed the process. The
accidentally deleted files I guess showed up with a path like this (without the prefix):

Delete 10B D:\$RECYCLE.BIN\etc\fonts\fonts.conf

The deleted file in this case would have been:
D:\etc\fonts\fonts.conf

As described in OP. I tried to reproduce this effect an a preview as well, but this time everything went fine. Btw, the recycle bin was empty while that happened.

[verdy_p (verdy-p)]

Beware that now Windows 10 makes extensive uses of hardw links. These does not cause problem because these links are counted and detroying one link does not destroy the other references.

But there are more tricky cases becaue now it also uses symbolic links and remount points (such as "junctions" in Windows terminology) impelmented as "reparse points".

You should not delete files inside a reparse point, you should only remove the reparse point itself, leving the target intact.

Note that some reparse points used by junctions can create infinite recursion if you navigate to them, notably for installations using the new "containers" (handled internally by Hyper-V and virtualization).

Bleachbit should not navigate inside these reparse points even if they look like a directory as it points somewhere else on the filesystem, and in this case the "$RD84L6V" folder was a reparse point within ""G:\$RECYCLE.BIN\S-1-5-21-259089694-2264239342-2853358479-1001" which is the normal recycle bin folder owned by user "S1-5-21*".

So make sure in Bleachbit to check the directory properties to see if it's a native directory (or hard link) and NOT a reparse point, do not navigate inside to delete the content, only delete the reparse point itself.

[verdy_p (verdy-p)]

Note that reparse points also exist to mount another volume in a directory (instead of mounting the volume on a drive letter with a root directory). This works much like the old option that existed also in old MSDOS and works exactly like mount points in Linux (using the mnttab or fstab) where there's only a single filesystem root for everything (possibly contextual per process group using a "chroot") and no concept of multiple "drives" and multiple "current directory per drive, like they exist in DOS, Windows, VMS...)

The Unix/Linux filesystems is simplified and does not handle current directory per device and per process, only one per process, so mount points are used inside directories instead.

Windows's reparse points are in fact the equivalent of mount points, they create a virtualization to conenct another filesystem or part of the current filesystem, but they are more powerful than Unix/Linux mount point because the target of the mount may be dependant of the user context or security level, and they may hide or expose some contents or redirect them into a virtualized storage (e.g. allowing changes of files owned by another, any change creating a private copy automatically that won't alter the content of the original files). Reparse points are now used a lot in Windows, and they save lot of space on disk and help secure it.

But Bleahcbit should not bypass this isolation: don't alter the contents inside reparse points, detect them, delete them if possible but do nothing inside what they expose inside if reparse points expose a directory interface. Usually reparse points should have security restrictions, but it's possible for the user with elevated admin privilege to remove the restrictions (this creates a security hole as this is not the normal setup) allowing them to modify the content that should have remained intact and not modified via the reparse point "weakened" by some inexperimented admin user.

Unfortunately Windows does not help much restoring the original security restrictions (even "SFC /SCANNOW" and "DISM ONLINE /RESTORE-HEALTH" will not restore the initial security, they just check the content of files) if an admin as removed these restrictions. Then tools like Bleachbit may think this deletion is safe.

In summary: don't scan and touch any files inside directories that are reparse points on Windows.

[Andrew Ziem (ahziem1)]

I made a change to not follow links in the recycle bin. Please test. This ticket has more information, including a way to test now.

https://github.com/bleachbit/bleachbit/issues/385#issuecomment-455751772