While saving text-compare changes: often error message

[Aaron]

Hello,

How have you configured Visual Studio 2012? Is it configured to launch BC4 as your difftool and is that how you are launching it here? If so, are you using BComp.exe and not BCompare.exe?
http://www.scootersoftware.com/suppo...?zz=kb_vcs#tfs

[Wessbie]

Same Error - Still on BC3 / Win 7 / VS2013

I have the same error message periodically as well. As stated by others, simply pressing the save button eventually gets the file to save (typically on the second try).

Beyond Compare Version 3.3.10 (build 17762).
Windows Pro 7 (6.1.7601 SP1 Build 7601).
Visual Studio Pro 2013 (12.0.30501.00 Update 2)
TortoiseGit 1.8.11.0 (msysgit 1.9.2)
SourceTree 1.6.11.0
Sophos Endpoint Security 10.3

Happens even when VS2013 is exited. If I exit SourceTree, I still have the error - but not sure if something stays resident, as it updates its status alot - so this is my #3 suspect. Tortiose is always updating icons - so that is a suspect (although surely it doesn't poll). And I would also suspect a virus scanner. ...or it could be something else...

Mostly I see the error when launching from the Windows context menu (Select Left File to Compare - Compare To). I don't recall if I've had the error when launched from TortoiseGit.

Hope this helps.

[stimpy77]

I have the same problem, had it with BC3 and now with BC4, on two different machines in two different workplaces (new job), but always in my case in the context of "External Merge" for Atlassian SourceTree and git. At this point I think the issue should be reproduceable given this context, give it a shot, guys. Clone a git repo, create a couple conflicts, and use the External Merge feature of SourceTree. Fails 90% of the time.

However, I found that if I repeatedly hit "OK" and retry hitting the Save icon eventually it succeeds in saving. Seems to be a timing issue? Maybe as a workaround Scooter Software you guys can just wait a few tens of milliseconds and retry over and over until 20x (or so) tries have been made, since that's what works for me manually?

[rodeybc]

I have the same issue with BC4.0.5 (build 19480). I launched a folder compare,then a file compare, merged changes during the file compare and trying to save. Repeated clicking the Save button will eventually save successfully.

Windows 7 Enterprise
TortoiseGit

[Aaron]

Hello,

The Save method here is using a built-in Windows method to help save the file by creating a temp copy, then overwriting the original. In most cases this works without issue and is safer than the alternative, as if this is interrupted we have a full copy of the file (old or new) available. The other main method used to save a file directly writes into the original file (like how a Notepad Save works), but if this process is interrupted then this leads to a corrupt file.

We've tested with various source control solutions, and most work without issue when dealing with either save, but some users have a specific configuration where they run into issues like yours. We're working on improving this scenario.

In the meantime, there is probably another factor in your setup that is causing us to hit this hurdle. Do you have any other software running at the same time you could temporarily disable to narrow down which it might be?

[mickeysoft]

Just another "me too".

I have had the same issue forever, many different versions of BC, many different computers. I would say it happens about 80% of the time. When I do get the error message, I'm guessing about 50% of the time it will succeed after a couple of tries. And the other 50% of the time I give up after 10-20 retries...

I use Far Manager (http://www.farmanager.com/), again many different versions. I start BC from the command-line, usually through a batch file (bc.bat) with the following content:

@echo off
"C:\Program Files (x86)\Beyond Compare 3\BComp.exe" %*

Maybe this helps track down the issue.

Hope you will fix this soon - thanks!

Hello,

The Save method here is using a built-in Windows method to help save the file by creating a temp copy, then overwriting the original. In most cases this works without issue and is safer than the alternative, as if this is interrupted we have a full copy of the file (old or new) available. The other main method used to save a file directly writes into the original file (like how a Notepad Save works), but if this process is interrupted then this leads to a corrupt file.

We've tested with various source control solutions, and most work without issue when dealing with either save, but some users have a specific configuration where they run into issues like yours. We're working on improving this scenario.

In the meantime, there is probably another factor in your setup that is causing us to hit this hurdle. Do you have any other software running at the same time you could temporarily disable to narrow down which it might be?

[D.H.]

Please take responsibility for your software issues

I am a developer like many who use your software. I love it and have used it in the past and that I am at a new job,I purchased it for myself last week because I really can't live without it. The day I got it I even recommended to the office manager that she purchase it for the office.... and then I started running into this problem.

Imagine how embarrassed I would be if after she bought it for the office everyone experience this problem.

Please realize that it doesn't matter to your customers if the method you use for saving your files is standard, or safer, etc.. It doesn't matter if the real underlying issue is antivirus or some other program holding a reference to the file in some way that it shouldn't. It only matters that we can save our changes.

I need you to either figure out how to fix this or provide a config option so that those of us experiencing the issue can choose the unsafe way that Notepad and others use to save their files.

I am using the latest version of your software. No other program I have on my computer has any issues saving files, only yours. Please take responsibility for your software issues.

Hello,

The Save method we employ on Windows is a standard, provided function. Some programs save in-place, like Notepad. If this process is interrupted, it results in a corrupted file. Other programs, like BC3/4 or Word, save to a temp file. Only once the save is complete is a Rename used to overwrite the original file. If you are seeing this scenario where a rename is failing, it is good to test to see if you are able to manually Delete the original file, then Rename a .temp file in the same folder to the original file's name in the same test location. You will also want to test saving a .txt file on your user's Desktop/ using BC3/4, to see if this is a colliding background task (potentially antivirus) that is location dependent or independent.

If you are applying updates, I would suggest updating to the latest BC3.x release (3.3.12), to have all the potential bug fixes and enhancements it provides. All 3.x updates are free for 3.x users.

[Aaron]

BC 4.1's beta implements the unsafe method as a fallback if the first method fails. Because it is a beta, I do not recommend it for day to day work or data that is not already backed up, but we would appreciate your help testing this new feature:
http://www.scootersoftware.com/download.php?zz=beta41

I would like to stress that the save method we're using is using built-in Windows API; it really should work unless there's a program on your machine that's blocking this native OS support, so you may hit other issues with other software down the road.

[D.H.]

As a side note, I have found an easy work around to this problem. clicking on the folder/open-file-icon (in the beyond compare header next to the file path you are trying to save) and the closing the dialog always seems to resolve the issue. Opening that folder path in windows explorer also fixes the issue, though that is less convenient.

[skippyV]

I ran into this issue for the first time. Using BC3. The files I were comparing were both opened in Visual Studio. Once I closed Visual Studio, the Save operation worked. So VS must have kept a lock on those files. Not sure if others had the same circumstances though. (old thread, I know)