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…

Answer 1

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.

1. 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.”

2. 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)

3. 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.”

4. You should not be using this API for extremely long path names, it has been replaced in vista+ by IFileOperation interface

5. 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