Windows 10命名空间扩展：OpenFileDialog与临时文件夹问题

Hey Bert, awesome work building that custom archive namespace extension—being able to browse and edit archives directly in Explorer is no small win! Let’s break down why the system is dumping copies into that AppData cache folder, then cover your options to fix it.

First, the core reason: most Windows applications expect to work with real local file paths, not virtual data streams from your extension. When you double-click a file in your archive namespace, Explorer checks if the target app can handle the IStream interface (the COM standard for passing in-memory data). If the app doesn’t support this (and many older or traditional Win32 apps don’t), Windows automatically extracts the file to a temporary cache directory so the app can open it like a normal local file. This is a fallback mechanism built into Explorer to maintain compatibility with the vast ecosystem of Windows apps.

You’ve got a few options depending on how seamless you want the experience to be, and how much work you’re willing to put in:

1. Implement IStream for Direct Access #

If you can get your extension to return an IStream instance for the file instead of relying on Explorer’s extraction, apps that support COM streams (like many modern Office apps or custom-built tools) will open the file directly without caching.

To do this, your namespace extension’s IShellFolder implementation needs to handle the SFGAO_STREAM attribute, and return a valid IStream when queried via GetUIObjectOf or CreateStreamOnFile. Keep in mind this won’t work for all apps—some stubborn ones will still demand a local path, so this is a partial fix.

2. Customize the Open Workflow with Temporary Files (Most Reliable for Broad Compatibility) #

This is the most common approach for full compatibility with all Windows apps. Here’s the step-by-step:

• Intercept the file open command: In your namespace extension, override the default "Open" action (you can do this via IShellExecuteHook or by adding a custom context menu item that replaces the default open).
• Extract to your own temp directory: Instead of letting Windows use its AppData cache, extract the file to a temp folder you control (use GetTempPath to get a system temp location, then create a unique subfolder for your archive’s files).
• Launch the app and monitor it: Start the target application with the path to your temp file, then use WaitForSingleObject or a process monitoring API to detect when the app closes.
• Sync changes back to the archive: Once the app is closed, check if the temp file was modified. If yes, update the file in your archive with the modified version.
• Clean up: Delete the temp file/folder once the sync is done.

Pro tip: Make sure to handle file locking—if another process is accessing the temp file, you might need to wait a bit before syncing, or notify the user to close the app first.

3. Use Windows Virtualization APIs (Advanced) #

For a truly seamless experience, you can leverage Windows’ virtualization features like Transacted NTFS or Volume Shadow Copy Service (VSS). These let you create a "virtual" file that apps can modify as if it’s local, but all changes are redirected back to your archive.

This is more complex—you’ll need to work with low-level Windows storage APIs, but it eliminates the need for visible temp files. It’s a great option if you’re targeting newer Windows versions and want the most polished experience.

4. Temporary Workaround: User Education #

If you need a quick fix while you implement the above, add a custom context menu option like "Edit and Save to Archive" that explicitly tells users how the flow works. It’s not ideal, but it lets users know they need to save their changes in the app, and your extension will sync it back (you can automate this sync on app close too, as in option 2).

内容的提问来源于stack exchange，提问作者Bert