Article ID: 202071
Article Last Modified on 11/21/2006
APPLIES TO
- Microsoft Win32 Application Programming Interface, when used with:
- Microsoft Windows 2000 Standard Edition
- Microsoft Windows XP Professional
This article was previously published under Q202071
SYMPTOMS
When you call MoveFileEx() with the MOVEFILE_DELAY_UNTIL_REBOOT flag, sometimes the system might not rename the specified file or directory successfully at restart.
RESOLUTION
To troubleshoot this problem, first check whether the location of the file or directory to be renamed is stored in the following registry value after the MoveFileEx() call:
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Session Manager\PendingFileRenameOperations
The system uses this registry value to complete the move operation at restart. When the MoveFileEx() call succeeds, this registry value is created. For the MOVEFILE_DELAY_UNTIL_REBOOT flag, the calling process needs to be in the context of a user who belongs to the administrator group or the LocalSystem account. By default, only Administrators and LocalSystem have write access to the
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Session Manager
registry key where the PendingFileRenameOperations value is created.
If the destination file or directory already exists and has to be replaced, the MOVEFILE_REPLACE_EXISTING flag also needs to be specified along with the MOVEFILE_DELAY_UNTIL_REBOOT flag when MoveFileEx() is called. Otherwise, the move operation fails without any error message when the system is restarted.
If the source file or directory is on an NTFS drive, the LocalSystem account or Administrators needs to have delete access permission on the source for the move operation to succeed.
If all these conditions are met, the system will move the source file or directory successfully at restart when the session manager is initialized.
Keywords: kbapi kbfileio kbkernbase kbprb KB202071