nurl and Word

July 13 2018

A more readable version: https://dev.nlited.com/p2201.htm

I have created a redirector driver to provide an interface (\\nurl) to files on a remote system. It is working, with one notable exception that has me flummoxed: Saving a file using Office Word.

The driver is a full driver implementation (what Microsoft now calls a "legacy" driver) to leverage a lot of existing framework code from other projects. I see every IRP in its original state. This is not a filter driver since there is no lower device to filter. I have FASTIO stubs, but they all return FALSE.

The remote file system will be very basic, definitely not NTFS. The current prototype stores the remote files in a subdirectory on the same local volume, so in this version the "remote" file system happens to be NTFS. This lets me pull NTFS information for the files to test theories during development, but this will not be possible in the final version.

All this is working. I can create, write, save, open, read, and update remote files using console commands (copy, type, etc). I can create, update, and save files using notepad.exe. I can list directories.

I can open and read existing files using Word. Saving files using Word fails. Word successfully saves the updated contents to a temporary file, then fails to replace the original file with the updated temporary file. In fact, Word does not even try to rename the files. I don't know why.

I can use Word to save a file on a "normal" network share and I see the following sequence: (Normal Log)

1. Create a temporary file.
2. Write the contents to the temporary file.
3. Set the saved file's LastWrite time.
4. Copy the security attributes.
5. Copy the file creation attribute from the original file to the temporary file.
6. Query the volume attributes.
7. Update the saved file's security attributes. (again).
8. Copy the NTFS OBJECT_ID.
9. Use IRP_MJ_SET_INFORMATION:FileRename to rename the original file to a temporary name.
10. Use IRP_MJ_SET_INFORMATION:FileRename to rename the saved file to the original name.
11. Write a NTFS USN_CLOSE record to the saved file.
12. Update the saved file's security attributes. (again).
13. Delete the original file (now with a new temporary name) using IRP_MJ_SET_INFORMATION:FileDisposition=DELETE.

When I save the file to my namespace, I see the following: (nurl log)

1. Create a temporary file.
2. Write the contents to the temporary file.
3. Query FileRemoteProtocolInformation
   NOT_IMPLEMENTED
4. Try to open a different temporary file.
   The file does not exist, OBJECT_NAME_NOT_FOUND:DOES_NOT_EXIST.
5. Query the original security information.
   The security info is returned as null (not empty), indicating no security. This is intended, since the ultimate remote file system will not support security descriptors. I have tried returning the actual security descriptor from the NTFS file, with no effect.
6. There is no attempt to set the security info on the temporary file.
   This is expected since the original file has no security info. I do not believe this is the culprit, but I can't be 100% certain.
7. Copy the file creation attribute.
   This version does not actually update the attribute. I don't see any further queries so I don't believe this is a problem.
8. Query the volume attributes.
   The remote volume supports a minimal feature set: no ObjectID, named streams, ACL, USN, etc.
   Word seems to be ignoring my volume attributes and trying to update ObjectID, security info, and USN records anyway.
9. Query the original file's stream information
   This is unexpected, since my volume doesn't support streams.
   I have tried returning NOT_IMPLEMENTED and valid stream information. Neither made any difference.
10. Delete the saved file's OBJECT_ID and query the original file's OBJECT_ID.
    I return NOT_SUPPORTED for both. There is no attempt to set the saved file's OBJECT_ID.
11. Query the original file's FileNameInformation.
    I return "\nurl\MyServer\Test.txt"
12. Query the original file's Basic info.
13. Try to open a second temporary file (same as before)
    The file still does not exist, OBJECT_NAME_NOT_FOUND:DOES_NOT_EXIST
14. Write a USN_CLOSE record to the saved file.
    I believe Word has already deemed the saved file as unacceptable at this point. I expect to see the renaming operations before the USN_CLOSE. However, I don't really expect to see the USN operation at all since my volume doesn't support it. I return NOT_SUPPORTED.
15. Query the saved file's attribute information.
16. Delete the saved file using IRP_MJ_SET_INFORMATION:Disposition=DELETE.
    I don't actually delete the file, but do return SUCCESS.

The saved file contains the complete updated contents. I can open and read it using Word, and there doesn't seem to be any problem with it. But for some reason, Word refuses to accept it and tells the user that the save failed: "There has been a network or file permission error. The network connection may be lost. (\\nurl\MyServer\Test.txt)".

This is the debug output from the driver, which contains every IRP that is not handled. ("Not handled" means completed with a NOT_IMPLEMENTED status.)

Does anyone know what it takes to make Word happy?