SHFileOperation FOF_ALLOWUNDO fails on long filenames

Question

I'm using the following function to delete a file to the recycle bin: (C++, MFC, Unicode)

bool DeleteFileToPaperbasket (CString filename)
{
   TCHAR Buffer[2048+4];

   _tcsncpy_s (Buffer, 2048+4, filename, 2048);
   Buffer[_tcslen(Buffer)+1]=0; //Double-Null-Termination

   SHFILEOPSTRUCT s;
   s.hwnd                  = NULL;
   s.wFunc                 = FO_DELETE;
   s.pFrom                 = Buffer;
   s.pTo                   = NULL;
   s.fFlags                = FOF_ALLOWUNDO | FOF_SILENT | FOF_NOERRORUI;
   s.fAnyOperationsAborted = false;
   s.hNameMappings         = NULL;
   s.lpszProgressTitle     = NULL;

   int rc = SHFileOperation(&s);

   return (rc==0);
}

This works nicely for most files. But if path+filename exceed 255 characters (and still much shorter that 2048 characters), SHFileOperation returns 124. Which is DE_INVALIDFILES.

But what's wrong? I checked everything a million times. The path is double-null terminated, I'm not using \\?\ and it works for short filenames.

I'm totally out of ideas...

score 3 · Accepted Answer · answered Oct 10 '12 at 22:05

I think backwards comparability is biting you in the --- in several ways, and I'd need to actually see the paths your using and implement some error checking code to help. But here are some hints.

You would not get a DE_INVALIDFILES 0x7C "The path in the source or destination or both was invalid." for a max path violation, you'd get a DE_PATHTOODEEP 0x79 "The source or destination path exceeded or would exceed MAX_PATH."
These error codes(return value) do, can, and have changed over time, to be sure what your specific error code means, you need to check it with GetLastError function(msdn)
Also, taken from the SHFileOperation function documentation: "If you do not check fAnyOperationsAborted as well as the return value, you cannot know that the function accomplished the full task you asked of it and you might proceed under incorrect assumptions."
You should not be using this API for extremely long path names, it has been replaced in vista+ by IFileOperation interface
The explanation for why it may work in explorer and not thru this LEGACY api is - Taken from the msdn page on Naming Files, Paths, and Namespaces

The shell and the file system have different requirements. It is possible to create a path with the Windows API that the shell user interface is not able to interpret properly.

Hope this was helpful

Thanks, yes, it was helpful. I've tried IFileOperation::DeleteFile. Takes some wrapper code to do the administration, but it WORKS! Thank you! — user178379, Oct 19 '12 at 11:52
For your point 2 - from SHFileOperation function documentation: `Do not use GetLastError with the return values of this function.` — Mr_and_Mrs_D, Mar 17 '15 at 22:32
That's interesting, but regarding the use of GetLastError to be sure what the error code means, the documentation of SHFileOperation explicitely says "Do not use GetLastError with the return values of this function." — Melvyn, Mar 12 '18 at 09:56

score 0 · Answer 2 · answered Aug 28 '12 at 08:21

0

The recycle bin doesn't support files whose paths exceed MAX_PATH in length. You can verify this for yourself by trying to recycle such a file in Explorer - you will get an error message about the path being too long.

answered Aug 28 '12 at 08:21

Jonathan Potter

36,172
4
64
79

1

Thanks, but I already tried that. And deleting (and restoring) such a file with the Windows explorer does work. (Windows 7) -- But you're right, there are still limits in Windows. If I try to copy and paste (=duplicate) the file using the explorer, I get an error. – user178379 Aug 28 '12 at 08:52

SHFileOperation FOF_ALLOWUNDO fails on long filenames

2 Answers2