Defender prevents Photoshop and Blender from saving files

Help & Support
1

Hi,

Sometimes when I save a file from Photoshop or Blender Directory Opus locks the file and prevents the file from being saved.
Both Photoshop and blender saves files as a temp file first and then rename them to the intended filename. It is at this point that Opus seems to sometimes lock the file and prevent Photoshop/Blender from finishing up the save.

This bug only occurs if I save to a network drive and have a lister open to the target directory. And even then it's not every time but saving 10 files in a row will trigger it on at least one of those files.

I have had this issue for a loong time and only recently been able to narrow it down to Opus causing the bug.

2

Which file formats is this affecting?

Which version of Opus and Photoshop/Blender are you using?

5

For photoshop PSD files, for blender .blend files

Currently using the below version, but I have been having these issues for at least a year now.
Opus 12.29
Photoshop 23.5.1
Blender 3.3.0

I also forgot to mention that the problem seems to occur more frequently with increasing file sizes or rapid saves, like batch saving a bunch of files.

6

I need to look in more detail tomorrow, but PSD files at least should already be taken care of, unless something has changed on the Photoshop side of things. We try to avoid opening the temporary copy until it has been renamed. Maybe Adobe have changed the names they use which we depend on to detect when it's a temp file.

7

Nope, the bug is still definitely in place for Photoshop. Trying to save a 150MB file and it gets locked out every other attempt.

The same file works perfectly fine to save on a local drive or if I make sure no lister is open to the folder I am saving to.

8

Some years ago we changed Opus to avoid trying to thumbnail *.tmp files because of Photoshop and similar problems.

From testing with Photoshop (23.5.1) today, it only uses a temp file when saving over an existing file, not when saving a new file. When saving a new file, it writes to the final name directly, without any *.tmp file or rename at the end.

Are you seeing the problem when saving a new file, or when saving over an existing file?

Photoshop is also opening and closing the output file a bizarre number of times, which with a long/slow operation like a large file on a network drive is going to leave the window open for something else (not just Opus) to start looking at the file.

I'm not really sure what we can do about the non-tmp case here that would be reliable and not cause other problems or long delays thumbnailing other files. It's really something Adobe should fix; they shouldn't be releasing their write lock on the file until they've finished writing data to it. If they can't easily avoid that due to how their code is structured, they should at least be retrying when re-opening the file to write more data to it. (Or they can write to a *.tmp file first and then rename it at the end, even when creating a new file, which would solve the issue with Opus but possibly not with all other tools that do thumbnailing and indexing.)

It's possible File Explorer isn't triggering the problem simply because Adobe no longer provide a PSD thumbnailer for the Windows shell, so it isn't trying to thumbnail PSD files in the first place.

Regarding Blender, could you make a Process Monitor log of what happens when you save a file with that? Depending on how the saves are done, we may be able to avoid trying to thumbnail its files.

1 Like
9

I'm only seeing this issue when re-saving a file in photoshop, new files are always fine.

For blender I get the error no matter if it is a new file or not. It looks like blender does the same thing where it saves a temporary file called 'name'.blend@ before renaming that to 'name'.blend

I sent you a pm with the process monitor log

10

Strange, since we should ignore the .tmp file in that case, until Photoshop renames it at the end.

But it may turn out to be the same issue as with Blender files on that network drive...

We could try adding .blend@ to our exclusions list like .tmp but, after looking at the ProcMon logs you sent (many thanks!), I am not sure if it would fix the problem. I'm not sure Opus is really the cause.

I found the event where Blender failed to open a file for writing (Sharing Violation error, which makes sense so far). The name ended in ...Into and Outro.blend@.

I filtered the log on all paths containing Into and Outro.blend, with or without the @.

Lines including the @ are highlighted in light blue.

The line where Blender can't open the file is selected in dark blue.

BlenderLog
BlenderLog1972×1698 316 KB

You mentioned that you saved everything twice, as the first run succeeded. I think most of the activity earlier on can be ignored in that case, and we can focus on what happens from 08:23:32 onwards.

(Also, the last two dopus.exe/QueryDirectory events just before that, at 08:24:20, indicate Opus looked for the .blend@ file but it did not exist at that point in time. I think that is Opus processing a backlog of change events and testing if a new file still exists, then finding it doesn't exist.)

Focusing on just the bottom, then:

image
image1972×518 100 KB

This seems to show Opus only tries to open the file after Blender fails to open it. It's possible the real order of events is different to what shows up in the log, perhaps, but there is a good half a second between them so I'm not sure it could be out of order.

The thing that opens the file before Blender is MsMpEng.exe, Microsoft's antivirus.

Having Opus monitoring the directory could be triggering the antivirus to scan the files, perhaps, but it ultimately looks like the antivirus is what's holding the lock.

There is also a mystery here, which may mean I've missed part of the picture: I can't see where the .blend@ file that gets locked is actually created. It may be created under another name and then renamed to .blend@, but I wasn't able to find it that event, even with all filtering turned off in the log. It's possible I missed it in the other details, but could also indicate something unusual going on with the logging or the way the network server works.

In any case, though, it appears to be Microsoft's antivirus which is locking the file, not Opus, at least assuming the order of events in the log is correct.

There's a report of a similar issue with Microsoft's antivirus here, where adding the folder to the exclusions list fixed things:

That might be worth a try for both the Blender and Photoshop issues on that network drive.

1 Like
11

I will try adding those folders to exclude list on Monday and see if the error remains!

I do think the server or network sped may play a part as well. I can work for hours without issue and all of a sudden I can't save anything. When I did the initial bug report the file export crashed after 1 or 2 files every attempt. When I did the process monitoring I hade to run it twice before it stoped.

Blender also saves backup files named .blend1 etc. not sure if that makes the log make any more sense.
.blend is the actual save files.
.blend# backup of the main file.
.blend@ temp file.

Blender starts by renaming the existing file to .blend1. Then it writes all data to the .blend@ file. Once it's done it renames it to .blend

1 Like
12

This solved both the photoshop .tmp file issue and the blender file issue!

I found that excluding the filetypes worked best, I tried excluding folders but when the files were buried to deep inside subfolders the problem came back.

1 Like