Page MenuHome

Windows move files to recycling bin when deleted in file explorer
Needs ReviewPublic

Authored by Robert Guetzkow (rjg) on Mar 25 2019, 1:30 PM.



This is a patch for T61412 which introduces a soft-delete for the file explorer on Windows. The IFileOperation interface is used for Windows 8 and later, older Windows versions use the legacy interface. The patch includes code from D4579 @Kris (Metricity) who implemented the function using the legacy API, is used for older Windows versions. I have tested the patch on Windows 10 using long paths, including Umlaute in filenames.

Diff Detail

rB Blender

Event Timeline

There are a very large number of changes, so older changes are hidden. Show Older Changes

Wrong header, causing build errors on win7, from the docs

Header	shobjidl_core.h (include Shobjidl.h)

use Shobjidl.h instead.


Given FOF_ALLOWUNDO seems to do the trick for pre-windows 8, I don't think we need two separate codepaths here.


Not as much as a comment as a question, the file browser didn't seem give me the option to delete a folder, so I'm not sure how to test this?

This revision now requires changes to proceed.Mar 25 2019, 4:01 PM

Fixed header include, should now work on older platforms as well.

Robert Guetzkow (rjg) marked an inline comment as done and an inline comment as not done.Mar 25 2019, 4:38 PM
Robert Guetzkow (rjg) added inline comments.

Yes it's better if some more experienced developers take a look at the COM interaction.


You're right I missed that the flags aren't available when build on the older platforms. Does it move the file to the recycling bin though?

I think it's fine to call CoInitializeEx multiple times, the main issue is ensuring we don't call it with different values. I'm not sure there is a good way to automatically ensure it's not called with different values. If someone adds another call to CoInitialize in the future I would hope they read the documentation and then search for any similar calls in the code and verify it's ok.


Can confirm this works on Windows 10 as well. It doesn't seem to be documented behavior to move files to the recycling bin with this flag though, at least not for the new interface.

I think it's fine to call CoInitializeEx multiple times, the main issue is ensuring we don't call it with different values. I'm not sure there is a good way to automatically ensure it's not called with different values. If someone adds another call to CoInitialize in the future I would hope they read the documentation and then search for any similar calls in the code and verify it's ok.

Allright lets keep it as is then, also keep the call to CoUninitialize since they need to be balanced.

The COM handling seems to be a bit difficult with the CoInitializeEx() CoUninitialize(). As per the documentation I'm not exactly sure what they do on CoUnitialize that requires it to be called before closing the application (and not sooner). I'm not sure how we could satisfy this besides moving them to Blender's startup/exit code. Perhaps using the old interface is the better solution for now, if that causes too much of an headache.

I've tested multiple subsequent file deletions and there was no problem, even with how CoUninitialize() is currently used. Not sure how sound this solution is, but it's working in my test environment.

They do some expensive cleanup when the refcount hits zero apparently, but i'll be honest, it's not like we'll be calling this 100.000 times a second on a regular basis....

@LazyDodo (LazyDodo) That's what I thought. I wish they would properly document their API and give reason as to why certain recommendation are made (or even whether that is mandatory or a recommendation). I'll do some tests with the backward compatible flags and if some others should be included as well, like FOF_WANTNUKEWARNING. It would be great if someone could test this on Vista, just in case something behaves differently.

  • Only use backward compatible FOF_* flags
  • Make progress silent, but show system dialogs when an error occurs, especially when a file would be permanently deleted because it can't be moved to the bin
  • Removed legacy interface, since code should work for Windows Vista and newer versions
Robert Guetzkow (rjg) marked 4 inline comments as done.Mar 25 2019, 7:19 PM

Corrected error handling. Only CoUninitialize() when CoInitializeEx() returns either S_OK or S_FALSE both of which have a positive return value.

I'm not familier with the WIN32 API, some topics regarding this patch.

  • We should prepare a solution for Linux/macOS/WIN32 in a branch and commit it into master for all platforms at once since having delete behave differently on each platform is no good.

    At the very least we shouldn't release with some platforms unsupported.
  • We could support 'hard' delete still (shift-delete for eg) - although this can be applied later.
  • Wouldn't use the name 'recycle', but thats easy to change (could call BLI_delete_soft ?).

@Campbell Barton (campbellbarton) I agree. I'll have to read up on how to implement this for macOS or perhaps somebody more familiar with the platform could join in. I think @Kris (Metricity) would like to contribute to this as well.

Currently a bit busy, but this isn't forgotten. When I got some time I'll implement the Linux soft delete based on the approach that trash-cli uses.

I would like to implement support for $topdir, but in case (1) and (2) fail (see spec) refuse to trash. This means we can simply use rename since we don't move files over across devices. This makes the code simpler and doesn't require reimplementing mv.

We really should use command line utilities, similar to Electron:

I do not want to have an implementation of the trash specification in Blender, it's too complex, we shouldn't be maintaining this kind of thing ourselves.

I think the complexity is manageable, but that is your decision. The problem that I see with the Electron approach is finding out what desktop environment we're on (which implies what CLI utility can be used). Does Blender already have an equivalent of libgtkui::GetDesktopName?

I think we can do this rather simple, not supporting older desktop environment versions. In such cases there would just be no move to trash function in the file browser.

If getenv('XDG_CURRENT_DESKTOP') equals KDE we use kioclient5 and otherwise use gio.

That would be an option, although I'd favor a general solution that works on all Linux distributions and desktop environments. @Campbell Barton (campbellbarton) @LazyDodo (LazyDodo) Do you agree with this approach?

@Brecht Van Lommel (brecht) just in case you change your mind: I have implemented the trash specification (currently without directory size cache).

I will not accept a patch with an implementation of the trash specification, especially not a custom implementation. Correctly handling all the errors and corner cases is hard, we should use a mature implementation rather than spend time on this ourselves.

We should just use gio and similar, then we can make the implementation very small and reliable.

Sure, no problem. I'll implement it today. Do you have any special security policies regarding system() for calling the CLI utilities?

Work in progress implementation of soft delete for Linux and macOS

Several small fixes. Sorry for spamming the tracker.

Removed unused argument from Windows delete_soft()

I can't test the macOS implementation, perhaps somebody can help with that . I'll test the Linux implementation later this day.

@Brecht Van Lommel (brecht) let me know if you want to change anything.

Fixed wrong debug print function for Linux.

Added missing include for macOS

Replaced malloc with Blender's allocator.

Correct error messages

@Campbell Barton (campbellbarton) I think this patch is done, if we want to limit the supported desktop environments as @Brecht Van Lommel (brecht) suggested. And if it works properly on macOS which I haven't been able to test.

Since I've implemented the full spec anyway, I've published it on GitHub. Perhaps somebody finds it useful.

Brecht Van Lommel (brecht) requested changes to this revision.May 5 2019, 11:55 AM
Brecht Van Lommel (brecht) added inline comments.

This will not compile as objective-C code needs to be in its own .m or .mm file. Adding in GHOST may be the easiest solution.


No need to use NSLog, use printf instead.

Ideally what should happen for all platforms is that any error messages are reported back to the user, not logged or printed to the terminal.


I think we can use gio always when it's available, even if the desktop environment is not GNOME or there is no detect desktop environment. That way it works with e.g. XFCE.


Use BLI_sprintfN to avoid having to manually compute the string length.


This will not work if the filepath contains spaces, system will interpret them as separate arguments.


This will try to free a NULL pointer when no desktop environment is detected

This revision now requires changes to proceed.May 5 2019, 11:55 AM

I'm currently quite busy, updates may take a while. Hopefully I can squeeze these in next weekend.


Yeah, sorry I'm not familiar with macOS development. I don't know what GHOST is, perhaps somebody else can implement this part.


Right, will add quotation marks.


Which is the same as a no-op. Can change if that you'd like to handle this differently


Yes, I can help with that part if the rest is done.


Strictly speaking, that's still not safe. If the filepath contains quotes you will still have issues.

You could use fork() and execlp() instead:


It's not a no-op, MEM_freeN will print a warning when passing NULL.


Yes this is a better and safer alternative to system().


My bad, yes there are additional checks in Blender's free.

Since 64acb70e7f0f removes the ability to delete files, is development on this patch still of interest?

@Robert Guetzkow (rjg) I think so. If you can make sure that it only affects Windows, or can also add Mac/Linux support, then I can't see why we shouldn't still add this. Preferably we should try to add support for all three at once I think.

  • Simplified Linux soft delete, now using fork and execvp
  • Added keymap entries back
  • macOS currently commented, because changes necessary to make Objective-C work
  • removed duplicate include for <sys/stat.h>

I've done some more research and it seems we could use the runtime with pure C on OSX. Certainly not the most elegant approach. @Brecht Van Lommel (brecht) do you want to take this from here?

This comment was removed by Robert Guetzkow (rjg).

@Brecht Van Lommel (brecht) This implementation using only C (and not Objective-C) could work. It would require linking CoreFoundation and Cocoa.

Let me know if you'd like to see this implementation for macOS in Blender or what other approach should be used.

This seems overall fine, but it will have to wait for 2.81 since it wasn't finished before the feature freeze.

macOS implementation of soft delete using the cocoa runtime.

This would be great to get in for 2.81, with the updated File Browser work happening, it fits well.

Robert Guetzkow (rjg) added a comment.EditedMon, Sep 2, 5:21 PM

Sure, just let me know what additional changes are necessary. I'm currently a bit busy with a project for university, but I'm sure I'll find some time to update the patch.

One area that would need improvement is the feedback to the user when an error occurs.