Monitor deletions and changes on NTFS volume with MFT_ENUM_DATA

Question

I'm using this code to fill a database of all the files on disk:

TCHAR szVolumePath[_MAX_PATH] = L"\\\\.\\d:";

HANDLE hDrive = CreateFile(szVolumePath, GENERIC_READ, FILE_SHARE_READ | FILE_SHARE_WRITE, NULL, OPEN_EXISTING, NULL, NULL);

MFT_ENUM_DATA_V0 med = { 0 };
med.StartFileReferenceNumber = 0;
med.LowUsn = 0;
med.HighUsn = MAXLONGLONG;

DWORD cb;
PUSN_RECORD pRecord;

unsigned char pData[sizeof(DWORDLONG) + 0x10000] = { 0 }; 

while (DeviceIoControl(hDrive, FSCTL_ENUM_USN_DATA, &med, sizeof(med), pData, sizeof(pData), &cb, NULL) != FALSE)
{
    pRecord = (PUSN_RECORD)&pData[sizeof(USN)];
    while ((PBYTE)pRecord < (pData + cb))
    {
        wstring sz((LPCWSTR)(PBYTE)pRecord + pRecord->FileNameOffset, pRecord->FileNameLength / sizeof(WCHAR));

        // file the database

        pRecord = (PUSN_RECORD)((PBYTE)pRecord + pRecord->RecordLength);
    }
    med.StartFileReferenceNumber = *(DWORDLONG *)pData;
}

Once the loop is finished, the database is successfully filled.

But how to continue (as a background task) to monitor in realtime the file changes / deletions? (example: display a MessageBox() "File readme.txt has been renamed.")

Should I re-launch such a loop every 1-second, with med.StartFileReferenceNumber = the highest FileReferenceNumber seen before?

---

Note: I'm a bit reluctant to launch this code every 1-second (99% of the time, for nothing). Doing it every 10-second instead would avoid using so much resource, but there would be a delay before detecting changes, whereas I do know some indexing software that don't have such delay.

Note2: I read How can I detect only deleted, changed, and created files on a volume? but the purpose of the main answer is to run it once, and not constantly in background.

Note3: I have looked at this useful code example from Microsoft Keeping an Eye on Your NTFS Drives: the Windows 2000 Change Journal Explained .

Note4: Should I keep FSCTL_ENUM_USN_DATA for initial database loading, and then use FSCTL_READ_USN_JOURNAL instead?

Note5: ReadDirectoryChangesW or FindNextChangeNotification (the former gives full path of changes in the notifications, the latter doesn't) cannot really be used because it won't give the FileReferenceNumber of a deleted file (one would have to open the file and use NtQueryInformationFile to get it; but this is impossible for deleted files); and FileReferenceNumber is necessary to update the file database (the file database uses a map / dictionary with FileReferenceNumbers as keys).