Author Topic: Needs to give error on sharing violation when trying to write (Read 2010 times)

Scott Bilas · « **on:** February 03, 2010, 06:30:31 pm »

I just found a serious problem in HippoEdit. I spent the last couple of hours trying to debug the entirely wrong issue because HE was not saving a file that I thought it was.

Apparently HE does not give an error on a sharing violation. I was editing a file, that a separate app later locked. If I made a change to the file in HE and saved it, it would appear to work just fine. Yet if I reload the file, then all of my changes are gone.

Expected behavior: HE should give an error when it tries to save a file and fails for any reason, including a sharing violation. It should not consider the file saved until it successfully writes it to disk.

Here is the entry I get when running Process Monitor:

5:16:22.9506743 PM HippoEdit.exe 5324 CreateFile C:\proj\spasm\shared\tools\source\Tools.targets SHARING VIOLATION Desired Access: Generic Write, Read Attributes, Disposition: OverwriteIf, Options: Synchronous IO Non-Alert, Non-Directory File, Attributes: N, ShareMode: None, AllocationSize: 0

HippoEDIT ( 1.47.753, 12/21/2009, Windows 7 64 bit (Build 7600) )

alex · « **Reply #1 on:** February 03, 2010, 07:07:01 pm »

Hi Scott,

yes, this is looks bad and should be fixed... But it can be once more Window 7 64 bit specialty...
Because normally if file is locked by external process and HE is not able to get exclusive access on write, it will report to you that file is locked by external app and will not allow to save. I have done a test on XP machine with two HEs running in exclusive and non exclusive mode (Tools->Options->Editor->Keep files locked while editing them) and verified that it is still works.
It can be that lock was done, and HE does not noticed that...
So, can you share a little bit more details to help me reproduce this:
- Is this a Windows 7 64 problem only or can be reproduced also on XP (if it is possible to check)
- Do you have an write rights for C:\proj\spasm\shared\tools\source\Tools.targets ? (think so, but who knows

)
- How have locked the file? Which app. Can you get the same with two HEs?
- Have you switched apps after file was locked by external app?
- Is modified flag was cleaned from document in HE after save?

Thanks a lot.

I will try to solve this in next beta, but I do not have Win 7 64 bit now for testing. So would be good to reproduce this on XP or Vista.

Best regards,
Alex.

mlwang · « **Reply #2 on:** February 04, 2010, 01:21:15 pm »

Couldn't reproduce it here, either. My system: Window 7 x64, HE 1.48 beta 757.

I tried first to lock the test file (a simple .log file) with HE, and then opened the same file with a 2nd instance of HE. The latter opened with a light-blue background for the whole editing area, signifying that the file had been locked.

I then did the same with Emeditor as the locking application. Same result.

Third test, Opened test.log with HE in unlocked state. Then opened the same file with a 2nd instance of HE. Now, with both instances running, enabled the "Keep files locked" option for the 1st HE. The moment I activated the 2nd HE after that, a window popped up saying:

Quote

r:\temp\test.log
This file has been locked outside of the editor!

Clicked OK to dismiss the warning, and HE's main editing area turned light blue.

Finally, I repeated the previous test with Emeditor as the locking application. Same result.

So I guess it's not Windows 7 x64 specific. Something else is at work here.

alex · « **Reply #3 on:** February 04, 2010, 11:25:06 pm »

hi Ming-Li, thanks for the test. Good to know that this is not one more Windows 7 64 bit problem...
So probably we need to wait here for more explanation from Scott, probably in his case something is different.

One situation that maybe can cause this, is when file was locked in the background (without actions from user with switching apps).
In this case maybe lock was not recognized... In this case logic in HE is different and was not tested too much.

Scott Bilas · « **Reply #4 on:** February 05, 2010, 05:32:35 pm »

I'm having trouble figuring out how to reproduce this outside my specific scenario.

In my particular case, I am using Visual Studio 2008, with the .csproj using an <Import> tag on a .targets file that I am editing in HE. For the entire time that VS2008 is open, any time HE saves the .targets file, the changes are lost. I can make a change in HE, then immediately do File|Reload, and the changes disappear.

So somehow VS has the file locked and HE does not learn about it. Is it possible that VS is locking the file in the background while HE has the focus and it is not noticing?

I'm trying to figure out exactly what's going on here with a test app and can't reproduce the issue outside the above scenario yet.

Scott Bilas · « **Reply #5 on:** February 05, 2010, 05:40:38 pm »

I wrote a test app that tries a few ways to lock a file that HE has open (such as in the background) and it doesn't reproduce the problem. I'll work on this some more.

Scott Bilas · « **Reply #6 on:** February 05, 2010, 05:55:44 pm »

Ok I reduced this down to the simplest case repro. If you have Visual Studio 2008 and are willing to try this, it should repro the problem. I get 100% repro from this case:

1. Unzip the attached zip somewhere.
2. Add an entry to MSBuild in the registry as described at the bottom of this post, using the path to test.targets wherever you unzipped it.
3. Load up VS2008 and open ConsoleApplication1.sln.
4. Open test.targets in HE.
5. Modify the file a little in HE (type some chars or whatever), hit Save, then Reload.
6. The changes are lost!
7. Exit VS2008 and repeat step 5.
8. The changes are saved!

If you do not do step 2 above, it won't repro, and you will get a security complaint from VS on opening the SLN. To resolve this, you must add the .targets file as a safe import for MSBuild. It's annoying, but necessary in order to use a custom targets file in csproj's. (I've read that this is improved in VS2010).

To add it to the registry, go to either:
32 bit: HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\VisualStudio\9.0\MSBuild\SafeImports
64 bit: HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\Microsoft\VisualStudio\9.0\MSBuild\SafeImports

There should already be a long list of files there that are preinstalled for different .NET targets. Just add the path to test.targets there.

Example:
test.targets REG_SZ c:\proj\local\ConsoleApplication1\test.targets

Then when starting Visual Studio you will know it works because you don't get the security complaint and the problem reproduces.

Scott Bilas · « **Reply #7 on:** February 05, 2010, 05:57:54 pm »

I just tested with Notepad2 and it does not have this problem. So I don't think it's something weird the OS or VS is doing. Note that HE does notice that the file has been changed by Notepad2 and offers to reload it, so that part works ok.

alex · « **Reply #8 on:** February 08, 2010, 03:24:53 pm »

Hi Scott,

sorry for delay with response and thanks a lot for investigations and example.
I am on the way to test it

I have already add some fixes for cases when file is locked in the background, so I will see if this is working or not...

I will try to provide a fix in some days with new 1.48 beta.

Best regards,
Alex.

alex · « **Reply #9 on:** February 08, 2010, 11:10:35 pm »

Hi Scott,

unfortunately was not able to test your app yet (on some machines where I have C# installed, I do not have 2008, on others there is 2008, but no C#).
But I have uploaded new beta, which does a check for locked state on save. Can you please check if you problem is still inside with new 1.48.758.

Also, from your last post was not clear: what meant that "Notepad2 does not have this problem"? It noticed that file was locked or it saves data without any problem?

Best regards,
Alex.

Scott Bilas · « **Reply #10 on:** February 09, 2010, 01:25:21 am »

I'll try the new beta.

By "Notepad2 does not have this problem" I meant that Notepad2 saves the file just fine. If I have the file open in Notepad2 and I hit some keys then Save, it saves correctly. If I do the same in HippoEDIT, it apparently saves, but when I reload the file it shows that it has not saved at all.

Weird huh?

Scott Bilas · « **Reply #11 on:** February 09, 2010, 01:32:14 am »

I tested with 1.48.758 and issue reproduces. Note that I used the default install of HE instead of my configured version just to eliminate variables. Exact same thing occurs. No errors pop up, it simply doesn't save the file. When I do File|Reload after Save the changes are lost.

alex · « **Reply #12 on:** February 09, 2010, 01:39:00 am »

yes... so, this mean that probably reason is not locking and new beta will not help here. Do not think that Notepad2 can overwrite locked files (or open exclusively by another process, maybe reason is set of flags used for create file when saving in HE and Notepad2)
I think I need to try your example. I have tested it with 2010, but it works without problem (I have not changed registry that time). Another thing, I have not found test.targets somewhere among files in solution...
Will try to get 2008 + C# next days.

Scott Bilas · « **Reply #13 on:** February 09, 2010, 05:59:06 am »

Yes, I only tested in 2008, and I had to set the registry key for it to happen.

The test.targets file is in the zip under ConsoleApplication1, right beside the .sln file.

alex · « **Reply #14 on:** February 10, 2010, 06:45:07 pm »

Hi Scott,

I have reproduced it. The reason was sharing flags passed to CreateFile.
Have added as better error handling with report, if file cannot be open, as correction for sharing flags.
So with new beta, HE will save without any problem.

Thanks a lot for a bug report and good example!
Was difficult to catch that.

Best regards,
Alex.

News:

Needs to give error on sharing violation when trying to write