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.
is there an answer for this issue? Because I have frenquetly the same problem (B 2.93).
Thanks a lot
There wasn’t a definite solution in my case, only a workaround.
Eventually I didn’t save my files directly to a drive shared on a local network but to an interim location which is getting synced to a shared drive. Not ideal but not the biggest issue I have to deal with so I don’t mind it so much currently.
I think there might be more cases when this happens though. Debuk gave a good explanation why this might happen, but I’m not sure how to actually resolve it.
Thanks a lot. I agree with you because it is not a “blocking issue” but it is uncomfortable.
I experience the problem with “@” files as well. I’ll call it a “nuisance” problem, though. Here’s why:
The reason it’s a nuisance is because it’s easy to miss that small dialog as well as the console message at the very bottom-most frame of the screen. If you walked away and suffered a power interruption, you’d lose data, but I only have to notice the error and hit save again.
Being aware of how often it happens (to me, at least), I am in the habit of watching the title bar like a hawk for the tell-tale asterisk ( “Blender * [PATH:file.blend]” ) of an un-saved file. Again, it’s no more or less dilligence than I’d pay to make sure my save went through in any app, but it is definitely a bump in the longer road of a smooth production. Blender 2.93.7
I have suspected that it’s related to writing in a DropBox synched file location. I haven’t had the means or motive to test beyond trying saves outside of the synched folders. The problem (nuisance) did happen on non-synched locations, too. I’m curious how many people experience this. Equally curious how many users have never experienced it.
