https://support.tixati.com/settings%20-%20transfers%20-%20files

it confirms if i want to delete the file now. previously i had "direct to trash".

You must be using Windows.
From the news page:
• removed support for sending removed transfer files to trash on Windows version due to bad fallback behavior in API

well that mega sucks, thats like basic functionality missing. i would still like to have it even if its buggy. on my windows 10 it worked perfectly. maybe notify thats it is buggy and keep it? wait for sulution from windows/sdk?

or could there be at least a functionality like a "move to specific folder on delete" which simulates recycle bin? for each category?
1. i dont like a confirmation, i dont like too many clicks
2. i dont like my files staying if i remove the torrent

WinXP Integral Edition and Win11 23h2 have never had any problems with deleting files to the trash.
Instead of complete removing the deleting behavior settings, it is better to make an appropriate warning on problem versions of the system in the settings panel or pop-up when using.

Tixati was the best program I've ever found. But this is a dealbreaker for me. Now I have to use a program that I hate. But it sends deleted files to the Recycle Bin...

Never had an issue with the functionality on Win10 either.

What exactly is the "bad fallback behavior in API" that is sought to be avoided with the removal of this useful option?

If the trash is full or not big enough when you send something to the trash it will be deleted instead.

Were you setting FOF_WANTNUKEWARNING? That should tell the API to show a warning if the file is deleted instead of recycled even if FOF_NOCONFIRMATION is set.

Simply put, there is NO SAFE WAY to programmatically send files to the recycle bin in Windows, no matter the version.  If you see another program doing it, they are doing it in a way that could fail silently and directly delete the file.  (Which 95% of the time you can get away with because most users are oblivious.)

Unfortunately FOF_WANTNUKEWARNING flag does not always work.  And when it doesn't, the file is directly deleted.  This will usually happen on any removable drive or network storage or a Vbox share.

No, there is no way for the API to indicate that a file will be not be recycled and directly deleted.  It simply fails by directly deleting the file.  This is for SHFileOperation and IFileOperation both, with combination of flags.  The nuke warning flag WILL NOT always work, in fact, it only ever works if the issue is recycle bin capacity, and even then it isn't reliable.  And when it does work, it will block the SHFileOperation call from returning when it shows it's dialog.

There is also an undocumented IRecycleBinManager interface which is very hard to get information on, but again, even if you take the risk of using this undocumented interface which could change in the future, this approach is not safe because you can end up with a data race if there is another process using the recycle bin near the same time.

Getting rid of this shitshow was absolutely the right thing to do.  Perhaps bringing it back with a very stern warning dialog when "Direct to Trash" option is switched on will be the only way to go, and let the users take the chance if they want.

For anyone who might read this in the future, perhaps coming across it via a web search, here's a decent summary of the options https://stackoverflow.com/questions/23720519/how-to-safely-delete-folder-into-recycle-bin  ..... there's many other articles about it if you use the search function on SO.

>>Perhaps bringing it back with a very stern warning dialog when "Direct to Trash" option is switched on will be the only way to go, and let the users take the chance if they want.
i would take this chance any time of the day, i never had issues.

from the lats link, how about this?
You can use hack. You can emulate removing of file into Recycle Bin with you own code which will create all necessary system records in C:\$Recycle.Bin\UserSID folder. I tested this method on Windows 7 and it works correctly. It allows to ignore limitation of max size of Recycle Bin. Also it allows to move files from USB into Recycle Bin on any drive.

also maybe some manual checks can be made before doing the actual move to recycle bin? for example check if the recycle bin is present on the drive, check if its usb drive, etc.

Here's how it's done (incorrectly) in the Electron framework:

https://github.com/electron/electron/blob/main/shell/common/platform_util_win.cc
(find the function named MoveItemToTrashWithError)

This will only catch the situation where the drive has NO recycle capability.  You have to use IFileOperationProgressSink and use the PreDeleteItem call to check if TSF_DELETE_RECYCLE_IF_POSSIBLE is present in the flags.  If not, it's about to do a direct delete so you return E_FAIL to stop it, and pass this state back to your original trash function, which can then report the error to the rest of the program (eg. raise permanent delete prompt).

The problem is, it won't catch the situation where the recycle bin is present but too full to handle the file.  In that instance, the file gets silently deleted.

Unfortunately this is also the exact same way it's done in Qt.  You can look here:

https://github.com/qt/qtbase/blob/dev/src/corelib/io/qfilesystemengine_win.cpp
(find the function named moveFileToTrash)

Tested all this on Win7 and Win10, and fails to deal with a full recycle bin / too large a file properly.  By adding the FOF_WANTNUKEWARNING (which is not used in these frameworks, for good reason) you can get a modal window to pop up if the file is too big, but it will block return from the IFileOperation::PerformOperations call until the user clicks yes/no.  You can put it on a separate thread to deal with the blocking, but this is far from a good solution, especially dealing with multiple files etc.

Few options remain: The extremely undocumented IRecycleBinManager interface, or manually playing with the undocumented file structure inside c:\$recycle.bin.

thanks for getting it back! much appreciated!