MS Paint cannot save image files when TMP is redirected to RAM FS

Hello,

I have found a compatibility issue between Windows 11 Paint and SoftPerfect RAM File System. When the Windows TMP environment variable is redirected to a folder on a SoftPerfect RAM File System volume, Microsoft Paint cannot save image files.

I have been able to reproduce the problem consistently.

My environment:

• Windows 11
• Microsoft Paint (mspaint.exe)
• SoftPerfect RAM File System 26.9
• RAM File System volume: R:
• Temporary folder on the RAM volume: R:\Temp

My test results:

TEMP                    TMP                     Paint save
----------------------  ----------------------  ----------
Default (C:)            Default (C:)            Works
RAM File System (R:)    Default (C:)            Works
Default (C:)            RAM File System (R:)    Fails
RAM File System (R:)    RAM File System (R:)    Fails
R:\Temp                 C:\TempTest (SSD)       Works

The last row shows that Paint works normally when TMP points to an ordinary folder on the SSD. The problem is therefore specifically related to TMP being located on the SoftPerfect RAM File System volume, rather than simply having a non-default TMP location.

Basic file creation with

echo test > "%TMP%\test.txt"

succeeds, so the RAM volume is writable and the TMP directory is accessible.

While filtering Process Monitor for file-system activity involving R:\Temp during the failed save, I could not find any corresponding events. This may indicate that Paint fails during some preliminary operation or filesystem capability check before actually creating a temporary file.

The image was being saved to a normal folder on C:, so the destination folder does not appear to be the cause.

The error message I get: This file cannot be saved. Saving was interrupted, so the file was not saved.

Since SoftPerfect RAM File System is designed to support Windows temporary files, I would like to know whether there is a known compatibility issue with Microsoft Paint, or whether Paint needs a filesystem feature that is missing when TMP is located on a RAM File System volume.

If possible, could you investigate this behaviour and consider addressing it in a future version? I would be happy to provide additional information or run further tests if needed.

Thank you.

Thank you for the detailed report.

We tested the same configuration here with TMP pointing to a folder on a RAM File System volume, and Paint saves PNG files normally. Process Monitor shows what it does: it encodes the image into a temporary file in %TMP%, copies that file to the destination folder, then deletes the temporary copy. All of those operations succeed on the RAM FS volume. This suggests that something in your setup differs from ours.

Could you tell us which format you are saving in (PNG, JPEG, HEIC, ...), and whether it fails with every format or only some?

The reason your Process Monitor filter showed nothing is probably that it was set on the path. Some of the relevant requests go to the volume itself (R:\) rather than to R:\Temp, and a path filter hides them. Please capture it again like this:

1. Start Process Monitor, open Filter → Filter, click Reset, then add "Process Name is mspaint.exe" and click OK.
2. Clear the display (Ctrl+X), reproduce the failed save once, then stop capturing (Ctrl+E).
3. Save it with File → Save, choosing "All events" and the native PML format.

Then zip the PML file and attach it here. With that we will be able to see exactly which request fails and why.

Here are the requested process_monitor_logs.zip. While doing more tests, I discovered a pattern depending on the image file format. With this configuration:

TEMP = R:\Temp
TMP  = R:\Temp

When I opened an image and selected Save As:

PNG  Failed
JPEG Failed
BMP  Succeeded
GIF  Succeeded
TIFF Succeeded
HEIC Succeeded

Then I discovered something even more interesting: after successfully saving the image once in BMP format, saving the same image again as PNG and JPEG succeeded. In other words:

• The first attempt to save an imageas PNG or JPEG fails.
• Saving that same image as BMP succeeds.
• After that, saving as PNG or JPEG succeeds.

It seems that the problem occurs only during some kind of initialization or first-time operation performed by Paint or its image encoder. It does not appear to be simply a case of PNG/JPEG temporary files being unable to work on the RAM File System, because PNG and JPEG work correctly after a successful save in another format.

Please let me know if you need any additional tests or logs. I am happy to investigate further. Thank you again for looking into this.

Thank you for the logs. Now it is clear that this isn't a first-save initialisation issue. The cause is in Zone.Identifier.

Your image file carries a Zone.Identifier alternate data stream - the "Mark of the Web" that Windows adds to downloaded files. When Paint saves a PNG or JPEG, it writes the image to a temporary file in %TMP%, then copies the source file Zone.Identifier to that temporary file. RAM File System doesn't support alternate data streams, so it refuses R:\TMP\image.png:Zone.Identifier. Paint treats that as fatal, deletes the temporary file and reports that saving was interrupted.

This also explains the pattern you found. BMP is written straight to the destination with no temporary file, so there is no Zone.Identifier to copy. After that save, the open document is your new BMP, which has no Zone.Identifier, so the next PNG save has no Zone.Identifier to copy either and succeeds. With TMP on C:, the stream lands on NTFS that supports it, which is why only TMP location matter, not TEMP

There are two ways around it:

• Keep TEMP on the RAM FS volume and leave TMP on C:.
• Right-click your source image, choose Properties, tick Unblock at the bottom of the General tab, and click OK. Paint will then be able to save it as PNG or JPEG with TMP on the RAM volume. To unblock a whole folder at once, you can run this in PowerShell:
  

  Get-ChildItem "C:\path\to\folder" -Recurse | Unblock-File
  

If you prefer that your new downloads weren't marked in the first place, Windows has a policy for that: User Configuration → Administrative Templates → Windows Components → Attachment Manager → Do not preserve zone information in file attachments, set to Enabled. On Windows Home, which has no Group Policy editor, the equivalent is a DWORD value SaveZoneInformation = 1 under HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\Policies\Attachments.
Bear in mind that this applies to every download, not just images. So Windows will no longer warn you before opening a downloaded program or document. Files that are already marked still need unblocking as described above.


This issue isn't specific to RAM File System. Paint would fail and show exactly the same error with TMP on an exFAT volume, which doesn't support alternate data streams either. In practice Paint needs TMP to be on NTFS whenever the opened image came from the internet.

RAM File System leaves alternate data streams out deliberately. A stream is effectively a second, hidden file behind the same name, with its own data, caching, memory mapping, locking and sharing rules, so supporting them properly would mean a second data path through almost every part of the driver, plus saved images and folder sync. The payoff would be small. Streams are lost whenever a file is copied to FAT or exFAT, attached to an email or put in most archives, which is why Microsoft stopped using them for file properties after Windows 2000, and why hardly any software relies on them today. They are better known as a place where malware hides data than as a place where legitimate applications keep it. Mark of the Web is practically the only common use left, so on RAM FS volume holding temporary files it would not justify the extra complexity and risk.