From bcc5cc28c6dc5178e8f4fd0cc521034ae5def388 Mon Sep 17 00:00:00 2001 From: Daniel Wilhelm Date: Fri, 18 Apr 2014 17:22:18 +0200 Subject: 5.10 --- zen/IFileOperation/file_op.cpp | 14 +++++++------- 1 file changed, 7 insertions(+), 7 deletions(-) (limited to 'zen/IFileOperation/file_op.cpp') diff --git a/zen/IFileOperation/file_op.cpp b/zen/IFileOperation/file_op.cpp index 3591de12..5d4cfdc9 100644 --- a/zen/IFileOperation/file_op.cpp +++ b/zen/IFileOperation/file_op.cpp @@ -173,16 +173,16 @@ void moveToRecycleBin(const wchar_t* fileNames[], //throw ComError // Set the operation flags. Turn off all UI from being shown to the user during the // operation. This includes error, confirmation and progress dialogs. - ZEN_CHECK_COM(fileOp->SetOperationFlags(FOF_ALLOWUNDO | + ZEN_CHECK_COM(fileOp->SetOperationFlags(FOF_ALLOWUNDO | FOF_NOCONFIRMATION | FOF_SILENT | //no progress dialog box FOF_NOERRORUI | - FOFX_EARLYFAILURE | - //without FOFX_EARLYFAILURE, IFileOperationProgressSink::PostDeleteItem() will always report success, even if deletion failed!!? WTF!? - //PerformOperations() will still succeed but set the uselessly generic GetAnyOperationsAborted() instead :((( - //=> always set FOFX_EARLYFAILURE since we prefer good error messages over "doing as much as possible" - //luckily for FreeFileSync we don't expect failures on individual files anyway: FreeFileSync moves files to be - //deleted to a temporary folder first, so there is no reason why a second move (the recycling itself) should fail + FOFX_EARLYFAILURE | + //without FOFX_EARLYFAILURE, IFileOperationProgressSink::PostDeleteItem() will always report success, even if deletion failed!!? WTF!? + //PerformOperations() will still succeed but set the uselessly generic GetAnyOperationsAborted() instead :((( + //=> always set FOFX_EARLYFAILURE since we prefer good error messages over "doing as much as possible" + //luckily for FreeFileSync we don't expect failures on individual files anyway: FreeFileSync moves files to be + //deleted to a temporary folder first, so there is no reason why a second move (the recycling itself) should fail FOF_NO_CONNECTED_ELEMENTS)); //use FOFX_RECYCLEONDELETE when Windows 8 is available!? -- cgit