Participant

Answered

Windows: *.tmp Files everywhere ( XXXX_XXXXXX_MVM_X.tmp )

Forum|Forum|14 years ago
May 12, 2011
5 replies
64955 views

So today I got annoyed again while going through my HDD's seeing all those TMP Files Photoshop spawned like raging Rabbits while I was working with it.

I tried some solutions I found on the web but none of these REALLY worked so I tested if it's actually PS that's causing this and it pretty much looks like it allthough some of them were created by Bridge as deleting was not possible with Bridge running.

1. I opnened all 3 HDD's I'd usually find the files in ( D:, E: & F: )

2. I started Photoshop CS5 - This generated a single file on 😧 without extension: Photoshop TempXXXXXXXX

3. I opened a JPEG - Nothing happened

4. I saved the JPEG as a PNG - BAM! 11 Files written on my HDD's:

😧 5540_1373635_MVM_7.tmp & 5540_1373635_MVM_10.tmp
E: 5540_1373635_MVM_5.tmp, 5540_1373635_MVM_6.tmp & 5540_1373635_MVM_9.tmp
F: 5540_1373635_MVM_0.tmp, 5540_1373635_MVM_1.tmp, 5540_1373635_MVM_2.tmp, 5540_1373635_MVM_3.tmp, 5540_1373635_MVM_4.tmp & 5540_1373635_MVM_8.tmp

Bad enough they don't even take up space giving them a reason to exist.

By setting UAC to it's lowest setting ( I'm not amused ) they vanish once I close PS ( have to close PS! Just closing the file won't do ) which they haven't before but I do not really see that as a solution.

Any solution to this? Am I missing something?

This topic has been closed for replies.

Correct answer ssprengel

The Mondo Virtual Memory files are for the Mondo Framework that Adobe uses for certain operations in Photoshop, like the Liquify plug-in and perhaps writing a PNG file. If you have your TMP/TEMP environment variable set to C:\TEMP (the default location for TMP and TEMP are under your users folder) and have 10s if not 100s of gigs of freespace on C the files should go into C:\TEMP, but if there is not so much space available or the TMP folder points to somewhere complicated that the MF feels uncomfortable with, then it allocates those files on the root folder of various hard-drives, which can be a problem if some are on slow USB drives. They disappear when Liquify is closed if that's what created them, but I'm not sure about cleanup frequency from other operations. Files can have 0 bytes indicated in a directory listing but still have data written to them as long as they aren't closed or the buffered data hasn't been flushed to disk. They all might be created "just in case" you do something that uses lots of memory and could actually have zero bytes in them if you don't. Try using Liquify on a large image and see how large they become.

Legend

Other than what's been suggested above, I don't think you can force them to the disk of your choice.

And I wouldn't bet on this ever being solved in Photoshop CS5.x. Sounds like just the kind of thing that will never be acknowledged, yet magically go away in the next major version release.

I say this because it's not a crash, just an inconvenience ("delayed write error" most likely indicates a system problem, perhaps catalyzed by Photoshop, but not caused by it). Regarding "conflict" with sync and backup software, please explain further... If you could show it's beyond an inconvenience, perhaps that would put more pressure on Adobe for a patch.

Just so it's clear, please note that I'm not with Adobe; I'm just another user.

-Noel

Inspiring

Thanks for your support, Noel. I have some USB-disks that I backup my network to. My backup software is scheduled to keep them in sync with certain folders and partitions in my network. It's very well possible that the software gets confused when it finds MVM-files that it did not put there, or it wants to remove them because they're not on the source disks, and they are locked. Or it removes them while PS keeps writing - or PS deletes sectors that have been overwritten in the meantime. With this kind of programming, anything is thinkable. I doubt if the people who concepted this respected regular file I/O conventions. So yes, I suspect it causing file table and write errors, eventually corrupting my disks. What if it is a hotfolder for printing, uploading or emailing that PS starts putting files into? This can hardly be called an 'inconvenience'.

Inspiring

Not solved yet? Please let me know if it is. Same problem here. MVM files on random disks, probably the ones with the most free space, being a 2TB or sometimes a 3TB USB disk. TEMP environment variables are okay. The MVM-files conflict with sync and backup software and I suspect them generating delayed write errors etc. They should not be there anyway. I have a fixed disk (D) with 400GB free. How can I direct these files to that disk?

Durahl7445836Author

Participant

I'm using different Partitions for the OS and Applications to be able to wipe the OS one without loosing the Folder Hirarchy on the Application one as I take quite some pride on it - Don't ask, I'm just nerdy like that.

1x 240GB PCIe SSD ( 740MB/s Read/Write ):

C: 60GB 26% Free ( System, Boot, Page File, etc... )

D: 163GB 55% Free ( Application Executables )

2x 2TB HDD's in RAID-0:

E: 300GB 56% Free ( Drivers, Patches, Installation Executables, etc... )

F: 426GB 89% Free

G: 1000GB 70% Free

H: 2000GB 41% Free

Legend

You sure they don't go away when you close PS even with UAC enabled?

I just tested a fresh install of Photoshop CS5.1 on a clean system, with UAC enabled. I see *_MVM_*.tmp files show up in the TEMP folder, then go away just fine.

Your basic problem is that for some reason on your system the Mondo Virtual Memory manager apparently doesn't want to use the folder identified by TEMP.

Try this:

1. Determine what drive you want the MVM system to use, which has some gigabytes free.

2. Create a new TEMP folder at the root of that drive.

3. IMPORTANT: Make sure your username specifically has Full Control privileges.

4. Edit your TEMP and TMP environment variables to point to that folder.

5. Log off and back on again.

-Noel

Durahl7445836Author

Participant

Thanks for both your replies.

I just tested the UAC thing again and for some reason it works now ( the deleting part after an Application kill ) but I'll keep an eye on that.

How much free space would be required for the MVM Manager to feel "comfy" on a single HDD/Partition? I can't believe it would require more than 15GB of free Space ó__Ô

Concerning the TEMP/TMP Mod... Which Temp Folder are we actually talking about?

The User one at %USERPROFILE%\AppData\Local\Temp or the System one at C:\Windows\TEMP?

Legend

Durahl wrote:
How much free space would be required for the MVM Manager to feel "comfy" on a single HDD/Partition? I can't believe it would require more than 15GB of free Space ó__Ô
Concerning the TEMP/TMP Mod... Which Temp Folder are we actually talking about?
The User one at %USERPROFILE%\AppData\Local\Temp or the System one at C:\Windows\TEMP?

Well... I fooled with Liquify for no more than 30 seconds, and it wrote over 3 GB of temp files. It's not hard to imagine that at that rate it would exceed 15 GB in short order. It's hard to imagine that it needs this much temporary space, but these are real observations (on a 64 bit system with 16 GB RAM I might add).

Regarding the second question: Change or add USER environment variables to point to a new x:\TEMP folder, where x is your drive of choice with lots of free space.

-Noel

ssprengelCorrect answer

Inspiring

The Mondo Virtual Memory files are for the Mondo Framework that Adobe uses for certain operations in Photoshop, like the Liquify plug-in and perhaps writing a PNG file. If you have your TMP/TEMP environment variable set to C:\TEMP (the default location for TMP and TEMP are under your users folder) and have 10s if not 100s of gigs of freespace on C the files should go into C:\TEMP, but if there is not so much space available or the TMP folder points to somewhere complicated that the MF feels uncomfortable with, then it allocates those files on the root folder of various hard-drives, which can be a problem if some are on slow USB drives. They disappear when Liquify is closed if that's what created them, but I'm not sure about cleanup frequency from other operations. Files can have 0 bytes indicated in a directory listing but still have data written to them as long as they aren't closed or the buffered data hasn't been flushed to disk. They all might be created "just in case" you do something that uses lots of memory and could actually have zero bytes in them if you don't. Try using Liquify on a large image and see how large they become.