FindFirstFile / FindNextFile不返回文件夹中的所有文件

Question

Note: The question suggested as a duplicate discusses CreateFile , ERROR_FILE_NOT_FOUND , having existing handles on a file, and flagging a file to be deleted later. While it is a similar topic, none of those issues relate to my case.

I have the following method to delete a directory. I've been using it for a while without problems.

But recently, I've really been putting it through its paces with a large task deleting directories and files over a network path (just a USB drive connected to my router).

Everything seems to work great except for one area where it is not deleting all the files in a directory and so RemoveDirectory() fails. (I have added each file to a list and verified that list did not contain the files that were not deleted.)

All files are named very similarly and there is nothing unusual about the name of the files that are not returned or deleted. If I run the program again, it will delete the remaining files and then have the same error a little later on another directory.

bool CBackupWorker::DeleteDirectory(LPCTSTR lpszName)
{
    if (!DirectoryExists(lpszName))
    {
        ASSERT(false);  // Unexpected
        return true;
    }

    CFileFind find;
    BOOL bContinue = find.FindFile(AppendPath(lpszName, _T("*")));
    while (bContinue)
    {
        bContinue = find.FindNextFile();
        if (find.IsDirectory())
        {
            if (!find.IsDots())
            {
                if (!DeleteDirectory(find.GetFilePath()))
                    return false;
            }
        }
        else
        {
            if (find.IsReadOnly())
                ClearReadOnlyAttribute(find);
            if (!::DeleteFile(ConvertToExtendedLengthPath(find.GetFilePath())))
            {
                LogErrorV(::GetLastError(), _T("ERROR DELETING FILE : '%s'"), (LPCTSTR)find.GetFilePath());
                return false;
            }
        }
    }

    CString sPath = ConvertToExtendedLengthPath(lpszName);
    DWORD dwAttributes = ::GetFileAttributes(sPath);
    if (dwAttributes != INVALID_FILE_ATTRIBUTES && (dwAttributes & FILE_ATTRIBUTE_READONLY))
        ::SetFileAttributes(sPath, dwAttributes & (DWORD)~FILE_ATTRIBUTE_READONLY);
    if (!::RemoveDirectory(sPath))
    {
        LogErrorV(::GetLastError(), _T("ERROR DELETING DIRECTORY : '%s'"), lpszName);
        return false;
    }
    return true;
}

A couple of notes on the code: ConvertToExtendedLengthPath() adds a prefix so that paths longer than MAX_PATH will be allowed; however, although these names are fairly long, none of them exceed MAX_PATH . (In this case, the method just returns the input value.)

Also, I'm removing the read-only attribute on files and directories that have this attribute. But again, I've confirmed this is not coming into play on any of the files I'm currently working with.

Finally, this is not a case where the files I'm working with are changing. I am the only one with access to this external drive.

Has anyone seen any case where FindFirstFile / FindNextFile will miss a few files? Or where accessing files over a network share could interfere with the behavior of these functions?

Answer 1

I have personally not observed such odd behaviour while using FindFirstFile / FindNextFile combo.

However, if you want to delete a directory and its contents, here's a solution:

// VadaPoché_SO.cpp : Defines the entry point for the console application.
#include "stdafx.h"
#include <iostream>
#include <strsafe.h>
#include <Shobjidl.h>

HRESULT CreateAndInitializeFileOperation(REFIID riid, void **ppv) //this function is copied verbatim from https://github.com/Microsoft/Windows-classic-samples/blob/master/Samples/Win7Samples/winui/shell/appplatform/fileoperations/FileOperationSample.cpp
{
    *ppv = NULL;
    // Create the IFileOperation object
    IFileOperation *pfo;
    HRESULT hr = CoCreateInstance(__uuidof(FileOperation), NULL, CLSCTX_ALL, IID_PPV_ARGS(&pfo));
    if (SUCCEEDED(hr))
    {
        // Set the operation flags.  Turn off  all UI
        // from being shown to the user during the
        // operation.  This includes error, confirmation
        // and progress dialogs.
        hr = pfo->SetOperationFlags(FOF_NO_UI);
        if (SUCCEEDED(hr))
        {
            hr = pfo->QueryInterface(riid, ppv);
        }
        pfo->Release();
    }
    return hr;
}

int main()
{
    using namespace std;

    const wchar_t *dirFullPath = L"C:\\test1\\test"; //this directory, and its contents, if any, will be deleted.

    IShellItem* itemDirToDelete = NULL;
    IFileOperation *fileOp = NULL;
    HRESULT hr = CoInitializeEx(0, COINIT_MULTITHREADED);

    if (FAILED(hr))
    {
        cout << "CoInitializeEx failed. Error code returned: 0x" << hex << hr << endl;
        return -1;
    }

    if (FAILED(SHCreateItemFromParsingName(dirFullPath, NULL, IID_PPV_ARGS(&itemDirToDelete))))
    {
        cout << "SHCreateItemFromParsingName failed. Error code returned: 0x" << hex << hr << endl;
        return -1;
    }

    if (SUCCEEDED(CreateAndInitializeFileOperation(IID_PPV_ARGS(&fileOp))))
    {
        //Note: contrary to its name DeleteItem, this does NOT do the actual deletion. 
        //It only declares an intention to perform deletion.
        if (SUCCEEDED(fileOp->DeleteItem(itemDirToDelete, NULL))) 
        {
            hr = fileOp->PerformOperations(); //This is the statement that acts on the intention declared above. i.e. it deletes the folder.
        }
        fileOp->Release();
    }

    return 0;
}

Answer 2

Although both the Windows file system and the Windows implementation of SMB ensures that files aren't left out of a directory enumeration, even if the contents of the directory are changing, this does not appear to be a requirement of the SMB protocol itself . (I'm hardly an expert, though, so I may have overlooked something.) At any rate, regardless of whether the behaviour of your server is technically correct or not, you will presumably need to deal with it as-is.

I would guess that the shell API already deals with this situation, but in your case I would recommend against using it, because I don't believe it supports long path names.

If you know that there will never be an excessively large number of entries in any given directory, and that no other process will be deleting files in the directory at the same time you are enumerating it, you might prefer to read the list of files first and then start deleting them. I gather you've already built a proof-of-concept along these lines.

A slightly less time-efficient but more memory-efficient and I think more robust approach would be to enumerate and delete the files at the same time (as already shown in the posted code) but then loop around and re-enumerate until you find that the directory is empty apart from the . and .. entries. The only obvious downside to this is the extra round-trip to the server. YMMV. :-)