OK, this is driving me mad.
I googled a lot, usually people saving to the cloud having issues like this.
I set up a local file server here yesterday, and ever since even local saves won’t work.
(got nothing to do with machin3tools, switched it on and off, nothing seems to help)
Anyone any ideas?
Just curious, can you do “save copy”?
I can do both “save as” and “save copy”, it saves a [email protected] which works after renaming. Not really something that’d work in a pipeline though, it’d be good to figure out how to fix it.
I’ve seen a bug report, got closed because no blend file was attached, I might have to create a non production example for this. Doesn’t really matter what blend file though, it happens in every case for me.
Only happened after I set up my file server yesterday, but no idea why it’s impacting local saves as well.
Your file got saved with an @ symbol? So for example: “[email protected]”? What does the full filename including path look like?
Which cloud services are affected? I use Dropbox, not a local file server.
Also, sorry I can’t be of any help. I’m just asking questions out of pure curiosity.
Yep, “[email protected]”. I’m using a local fileserver, no web based services. But as said, it also happens when saving locally on the workstastion. (ever since I set up my local server yesterday)
I had the same issue today. When trying to save a new version of a Blend file it got stuck at the [email protected] file and I get the “Cannot change old file (file saved with @)”.
As I read that the ‘Compress File’ preference has recently been updated with a new compression method, I figured trying to turn that off, and it seems to work.
Maybe the compression option also caused the issue in older Blender versions.
For me it was an issue with the file server. Whenever I wanted to save on a shared drive I ran into this more often than not. I couldn’t really solve the issue as my IT skills are limited when it comes to local networks so I just do scheduled scripted backups daily.
If it happens with compression as well it would be interesting to hear a developers take, it almost seems like some sort of feature, or at least something intentional. 
In the mean time it turned out that the new compression isn’t the culprit. What I’ve noticed is that Blender seems to have an issue with saving incrementally, unless I delete the failed incremental save with the ‘@’ sign and save it again. Then it works. 
Interesting. I’d be curious what’s going on behind the scenes. I mean the @ files work fine after being renamed, it’s just a hassle.
@dan2 @Metin_Seven The file with the @ is a temporary filename that should be renamed at the end of that process, so no matter what keeps blender from finishing that process is the initial problem, if its now a full disk or resource permission problems. In any case it leaves the @ file version and cancels the save operation there.
Just guessing, but the resulting problem might eg be a remaining file lock or that for following saves the logic isnt programmed to handle cases with existing temporary files, if blender is eg just checking if the final filename exists but not for the temporary one.
@Metin_Seven did you try to save to the incremental number where the temporary @ file existed or is any incremental save not working?
This might explain the issues I had. Plenty of space left, but there might have been some issues around permissions which led blender to finish the save successfully but for some reason prevented it from renaming it. Our IT department couldn’t really figure it out either, then again, not sure how much effort was given to solve the issue.
Yes quite likely. But to me it sounds as if something more is going wrong if such temporary files exist during later saves.
It worked fine as soon as I started saving onto a non-shared drive again. A bit annoying but with some workarounds it’s not a deal breaker.
Yes, it produced the same error. It only works when I first delete the file with the ‘@’.
I also couldn’t open a 3.0 alpha file in 2.93, even after disabling the compression option. I wonder if the issues are related or not.
I meant it the other way around. I’d expect less of a hassle if the numbering is different from the existing @ files number. So does it happen with different numberings too that it causes an error
I’ll check that, thanks for thinking along.
