How can I get path to the recycle bin folder for a specific drive?

I'm curious if there's a way to get a path to the recycle bin folder for a specific drive for the current user?

Say, on the input one provides "C:\" and on the output you get "C:\$Recycle.Bin\S-1-5-18"

S-1-5-18 here is just a user's SID.

Igor, I understand that, but how do I know that Microsoft will keep the same format of the path? Or, for instance, Windows XP calls it differently. I'm asking for a more general way to retrieve it.

Have you seen this: http://blogs.msdn.com/b/oldnewthing/...8/8956382.aspx

Quote:

---

Originally Posted by STLDude

Have you seen this: http://blogs.msdn.com/b/oldnewthing/...8/8956382.aspx

---

Yes, I have. It kinda does the opposite thing though. To make it do what I need, I'll have to start searching the drive and call Raymond Chen proposed GetFolderDescriptionId() method on each folder I find. That will take a long time to complete!

typically speaking: No

The whole point is that the recycle bin is a "black box" that allows users to recover files they've recently deleted. The notion of asking about "what is the path to the recycle bin" is an indication you're doing something wrong somewhere.

Quote:

---

Originally Posted by OReubens

The whole point is that the recycle bin is a "black box" that allows users to recover files they've recently deleted. The notion of asking about "what is the path to the recycle bin" is an indication you're doing something wrong somewhere.

---

Well, let's see if you can do it right.

I've got to this question after trying to implement an option for users of my software to delete files or, most notably folders, into the Recycle Bin. The whole idea is to allow those folders to be placed into the Recycle Bin and not permanently deleted. (So please let's not go into the discussion of whether or not users should rely on the Recycle Bin. I'm just following the customer's specification.)

My software also allows to perform this file operation on schedule. Since the scheduled file removal may happen when the user is not present, I was not enable to use the UI from the SHFileOperation API itself for the warning of the permanent deletion, since its UI would block my program. On top of that my software allows removal of multiple files/folders and thus with the default UI users would have to see and respond to that warning for each file.

So to avoid all of the above, all I needed to accomplish is to know whether or not, a file or a folder would be placed into the Recycle Bin before I actually invoked the SHFileOperation in a silent, or no UI mode. Sounds like a simple question, right? Well, guess what, to the best of my knowledge, Microsoft did not provide means to answer it.

I first tried this approach, which I thought would work, but unfortunately it didn't provide a complete solution. It could only cover a situation when the drive did not have the Recycle Bin set up.

I then found an undocumented interface that supposedly can do what I need, but I failed to convert it from Delphi into C++. So if someone can tackle that it would hypothetically solve the problem for Vista and up.

Then someone suggested doing all the checks manually, i.e. see what is the current size of the Recycle Bin, and then see the size of the files/folders being deleted, which will kinda hint if the files would fit or not. So this part is easy to do.

But the second reason why files would not be placed into the recycle bin is the file path itself. The math on Vista and later is as follows:

A. If say, the folder being deleted is "C:\Users\Name\Desktop\folder being deleted" that contains the deepest subfolder item: "C:\Users\Name\Desktop\folder being deleted\subfolder 1\subfolder 2\file.txt"

B. And the location of the Recycle Bin on that drive is: "C:\$Recycle.Bin\S-1-5-21-239515087-2011499679-4033017687-1001"

Then we need to combine the two as such: "C:\$Recycle.Bin\S-1-5-21-239515087-2011499679-4033017687-1001\$Rxxxxxx\subfolder 1\subfolder 2\file.txt" and if this path is more than MAX_PATH -1 then the folder A cannot be placed in the Recycle Bin.

By now you probably see why I need to know the path for the recycle bin on a specific drive.

So having me explain all this I am now expecting OReubens to stand up for what he said and show me how to do it right.

Another option is to create your own equivalent of the recycle bin.

In other words, you create a folder where you move the deleted files and provide an interface where users can permanently deleted them or restore them. You'll need to track where the files originated from so you can move them back (um, restore them).

In reality this doesn't even need to be done on the file system. It could be any sort of persistent storage - even a local database (storing the 'files' as binary data).

Quote:

---

Originally Posted by Arjay

Another option is to create your own equivalent of the recycle bin.

---

Arjay, my first offer for this customer was an even easier approach -- to simply move the files to a "scratch" folder that can be emptied out later. Their response was that they want to keep what's already available in the operating system. They don't want to deal with 2 recycle bins. (And I truthfully understand that.)

Quote:

---

Originally Posted by dc_2000

Arjay, my first offer for this customer was an even easier approach -- to simply move the files to a "scratch" folder that can be emptied out later. Their response was that they want to keep what's already available in the operating system. They don't want to deal with 2 recycle bins. (And I truthfully understand that.)

---

Are they aware that the recycler functionality doesn't work the way they hoped it would work?

The recycle bin operates in a certain way, and if users aren't happy with how it works, that isn't something they should expect YOU to fix.

If you want deleted files to go to the recycle bin, then that's what SHFileOperation is for, you can if you so desire, supress all confirmations and default them to continue the moving to recycle bin (or actual delete if that's what'll happen for reasons outside of your control).

Assuming that the recycle bin is a folder and that files are actually stored in there is a wrong assumption, there are shell addons that replace the recyclebin with something else entirely that does the same "black box" thing, but does it differently internally. So trying to establish the actual folder is a path to problems unless you can guarantee no such recyclebin replacement is going to be used.
Even with the default operation, the recyclebin has behaved differently from version to version of windows, and even from SP within a certain version.
The quota limit is new since Win8
the size restriction on the recycle bin is also "new" (since vista iirc)
there are other restrictions and rules such as not putting certain files or folders into the recyclebin when they're being deleted (for security issues).

If you want more tight control over what happens, then you can install a file operation copyhook. See MSDN for ICopyHook::CopyCallback
this may or may no allow you to do what you want to achieve.


if the users want to change the behaviour of the recyclebin... Tell them to change the windows settings that influence the recyclebin. Expecting that your app does things differently than the same identical delete performed from WIndows Explorer are unrealistic. If that need is a dealbreaker, then the suggestion made by Arjay is the correct approach.

if "they want to keep what's already available in the operating system", then they should also agree and accept with how that very OS feature works. if they expect different behaviour, then what they want is a similar, yet different feature.