Where do deleted files on a network go?

Question

I have a home network Win 10 and Win 7. I often read files off one machine 7 from the Win 10 cuz the later is hooked up to my Big Screen TV.

I often delete Win 7 files from the Win 10 across the network. When I look in the Recycle Bin on Win 7 the files are NOT there! Nor in Recycle on Win 10 (which I didn't think they would be anyway.)

I just ran a test. Deleted a file on 7 from 10. Not showing in 7's Recycle. Then used Recuva to scan the folder and it showed the file. I was able to recover it. Pretty normal expectation.

So the Mystery is why it doesn't show in 7's Recycle Bin.

Answer 1

Deleting files from a network share deletes them permanently, same as if you sent them to the recycle bin and then emptied it. You should enable shadow copies on your networked drive to restore deleted files OR set up the share as a mapped drive and then enable recycle bin on that mapped drive on the PC connecting to the share.

Answer 2

The reason is that the Recycle Bin is a "special" folder whose functionality only works on the local computer when processing a delete command. The difference between the Recycle Bin and an undelete tool such as Recuva is that the Recycle Bin is a "safe" place to store files you may not have meant to delete. Files in it are guaranteed to be recoverable until you empty it on purpose. When a file is "actually" deleted, it may be recoverable with tools like Recuva, but there is no guarantee, and resorting to that means something has gone horribly wrong.

Bottom line is, the Recycle Bin is a convenience feature that helps you undo the deletion of your own files on your own computer. It doesn't work on other computers over the network.

If you're interested in the gritty details, read on... Otherwise, just accept this as the answer.

---

TL;DR

There is a regular (hidden) directory on the root of every volume on your computer called $Recycle.Bin. Inside this directory are subdirectories representing the SID (security identifier) of every user on the system who has ever deleted a file (every user has a unique SID). Windows represents the Recycle Bin on your desktop as a "projected" composite of all your user SID subdirectories of every $Recycle.Bin directory on all the drives on your computer.

For example, let's say your user SID is S-1-5-21-123456789-123456789-123456789-12345, and your computer has 3 local volumes (C:, D:, and E:), which can be 3 different hard drives, 3 partitions on the same drive, or any combination of the two. On each hard drive, you will have the following:

C:\$Recycle.Bin\S-1-5-21-123456789-123456789-123456789-12345
D:\$Recycle.Bin\S-1-5-21-123456789-123456789-123456789-12345
E:\$Recycle.Bin\S-1-5-21-123456789-123456789-123456789-12345

Windows will show you a single Recycle Bin icon on your desktop that contains files from all three of those directories. There are a couple of things you should be aware of with this setup:

• The Recycle Bin on your desktop only contains files YOU deleted. If there are other user accounts on the computer, you wouldn't see files THEY deleted, nor can they see yours. This is true even if you deleted a file from a directory that all users previously had access to. This has a side effect of giving one user the ability to "capture" files; no one can recover that file except the person who originally deleted it.
• When you "delete" a file, Windows actually performs a "move" operation to your $Recycle.Bin directory, renames it to something unique, and appends a bit of metadata indicating what it's name originally was and where it originally came from (so you can restore it later). This is why you can appear to have multiple files with the same name in the same directory, which you normally can't do.
• A "move" operation from one location to another on the SAME volume is instantaneous because only a filesystem pointer gets modified so as to make the file appear as if it's in a different directory. The system does not have to actually move the file's contents to the new location. However, you cannot "move" a file from one drive to another (Windows does a copy followed by a delete of the original in that case). This is why each drive has its own $Recycle.Bin directory. You wouldn't want a "delete" operation copying potentially huge files to another drive, which would take time and the other drive might not have enough space.

Additionally;

• The SMB protocol (the one behind Windows file shares) was not invented by Microsoft, and was designed to be computer-agnostic at a time before Windows was a thing. As such, it deliberately has no concept of the underlying filesystem of the computer the share is hosted on. This is why non-Windows systems can both host and connect to SMB shares; the protocol abstracts away the technicalities of the actual storage medium, allowing non-compatible devices (even phones and printers) to share files with each other.
• This is also why you can't "move" files between two different file shares. What you're actually doing is downloading the file to your own computer, uploading the file back to the remote computer in the new location, and then deleting the original. This occurs even if the two different shares are actually just different names for the same physical folder.
• The $Recycle.Bin directory is not shareable, because its contents are only meaningful to the computer it's actually stored on.

When you delete a file over the network, it's your computer's job to "park" the file in the Recycle Bin, not the remote computer's. This can't possibly work over the network. Here's why:

• Your computer does not have access to the remote computer's Recycle Bin, since it's not shareable.
• Even if it was shareable, you may not have an account on that computer to place the files into (like if the share allowed "public", anonymous users to access it for example).
• Even if you did have an account, what volume's Recycle Bin does it go into? Remember, "moving" files between SMB shares is actually a two-way copy. Your computer doesn't know about the remote computer's underlying storage.

Some of this could be solvable if the SMB protocol included some functionality for the remote computer to handle delete operations in its own way. But that would have its own problems:

• How would any other computer you use ever know to look at another computer's Recycle Bin for files you may have deleted from it?
• How would you empty the Recycle Bin if you or the remote machine were offline at the time? What if no longer have access to that remote machine? You'd be permanently unable to empty your Recycle Bin.
• If you restored a deleted file, where would it go? Share names, server names, and IP addresses can change all the time, and different shares on different machines can actually point to the same physical place.
• What if the remote share isn't on a Windows computer (or even a computer at all)? It would have no concept of a Recycle Bin to place files into.
• Many other problems I'm not even thinking of.

A lot of this is hard to wrap your head around when you only have two computers and you're the only person that uses them. But all of this becomes a huge problem in the wider scheme of things.

This is why, almost 40 years(!) after the protocol was developed, there still isn't any universally-accepted way of recovering deleted files over a network.