sharing violation occurred

When I am running MUSHclient (currently version 4.14) and try to edit the script file, I get an error when I save the script. Error is "A sharing violation occurred while accessing L:\ShadowSiege\myscript5.lua."

I'm not doing much strange. I start MUSHclient, open the world, use MUSHclient command to open the script file, make any change (even to a comment), and save script file. I get the error, and must close MUSHclient and restart in order to be able to do further scripting.

The odd thing is that when I first started scripting, I did not get this error.

Ideas? TIA.

What kind of drive is L:? Is it a shared network drive? It's likely that this is a problem with the drive somehow, and not related to MUSHclient or scripting per se.

This is strange, and the first time I have heard of this. To clarify, you are using scripting (a script file) in one world only? That is, you don't have multiple worlds open at once sharing the same file?

So, you open the world, which automatically loads the script file, is that correct?

Then, you edit the script file using the built-in notepad? Or have you set the editor to some other editor? You edit OK, but can't save it?

First thing to consider is, does MUSHclient keep the script file open? Well, here is the code in question:



You can see that the file is indeed opened to deny writing, however the last line closes the file, so it should now be possible to write to it. Judging by the MFC code, it should have thrown an exception if the file failed to close.

Does this happen the first time you edit the file? Or the second time? Maybe the editor doesn't close the file, especially if you use a different editor.

I would follow David's suggestion and try putting the script file on a local drive (like C:), as there may be problems with the way files are closed if you are using a network or USB drive to hold the file.

Also, I don't think this is related to Lua somehow. You could try temporarily making the script file VBscript (even with an empty file) and see if the problem persists.

Ok, lot's to look at. Summary: Changing to Notepad "solved" problem.

1) Good guess about USB stick. I'm trying to make a "Portable MUCHclient world" so that I can use the same .mcl and .lua files on 3 different computers (one Linux and two Windows XP). However, if I copy everything over to local hard drive (on XP system), after resetting all the pointers to script file, world file and log file, behavior still exists.

2) Answers to Nick's questions:
a) Only one world open (not even opening other worlds at all)

b) MC automatically loads script file, no problems.

c) Created an empty .lua file. I was able to open the file and edit it. Saving worked as expected, except that back in MUSHclient I received the error message. Next time I started the client, the previously saved changes were present.

d) The error occurs the first time I save file, but only if changes are made. Subsequent saves are not recognized by MUSHclient. That is, no errors occur, but the script file does not seem to be updated internally, either.

e) And finally, THE CULPRIT! I was using LuaEdit because I wanted to see the syntax highlighting. As soon as I changed back to "Use inbuilt notepad to edit scripts" the problem went away. Although I lose syntax highlighting (bummer).

f) I tried to insert the //open script file code in the .lua file, but got an error when opening the world. Probably I don't understand how or where to insert the code... I put it at the beginning of the .lua script, and got the following:

Compile error
World: ShadowSiege
Immediate execution
[string "Script file"]:14: unexpected symbol near '/'
Error context in script:
10 : --Note ("Log path is " .. logfilepath)
11 : --
12 : -- Make change
13 :
14*: // open script file
15 : CFile fileScript (m_strScriptFilename, CFile::modeRead | CFile::shareDenyWrite);
16 :
17 : char * p = m_strScript.GetBuffer (fileScript.GetLength ());
18 :

The ideal solution would be to get syntax highlighting, but I can live with notepad for small changes, and use LuaEdit for bigger changes. Thanks for the help.

That code I gave was C++ code from within MUSHclient - it won't work as Lua.

I suggest you use Crimson Editor - that has Lua syntax colouring and I have never experienced the problem you describe. It is free.

http://www.crimsoneditor.com/

An interesting experiment would be to try editing the file *without* first opening it in MUSHclient. Since MUSHclient opens and closes it immediately, it might actually be some sort of problem with the way LuaEdit works with files on USB drives. In other words, try editing the file without using MUSHclient at all. At least that would let MUSHclient off the hook.

First, many thanks for all the ideas. Crimson Editor works without the sharing violations, regardless of whether I'm loading from USB drive or local hard drive.

I tried some of the other things, too.

1) Opening lua file using LuaEdit, editing it, and saving it without opening MUSHclient works fine, whether or not I am using the local hard drive or the USB drive.

2) As expected, if I open the lua file in LuaEdit, and then run MUSHclient, everything is OK until I try to save a change in from LuaEdit. As soon as I try to save the open script file, I get the error. This does not depend on whether I'm using a local hard drive (my J: drive) or a USB drive (my L: drive).

3) Blush... I should have recognized the C++ code. Since my focus was on Lua, and I'm not that adept at it yet, I just assumed you were giving me Lua code.

SO the end result now is: Notepad and Crimson editor work as expected with MUSHclient. LuaEdit is still giving the error, with no diagnosis in sight. As I have a good workaround, I'm satisfied. Thanks again.

Hmm. I am betting that the problem is that LuaEdit keeps the file open and locked, so long as its running, so of course, the moment you try to change it with some other program, it bombs. This imho is a design problem of LuaEdit and I wonder if they intended it, or just never noticed.

It can be a desirable feature in some cases, I think, to leave the file locked. It would prevent somebody from editing it, saving it, and then you save it, clobbering whatever they did. ("You" and "they" could be several programs on the same machine, not actual people.) But as you say it's quite possible they just never noticed it... :)

I use LuaEdit at work (shh, don't tell my IT department), and I have never experienced a problem when trying to run the scripts off of an instance of lua5.1.exe for execution.

Actually, now that I look at what I'm doing... I'm using wxLuaEdit. That may operate a little differently as far as file locking, but it still deals with the syntax highlighting. I cannot test when MUSHclient opens a file, as they have telnet blocked on my stupid network, so I haven't bothered putting MUSHclient on my new USB drive.

Also, file locking should not matter too terribly much if it is read only. The system should be able to read the data off, since that is not altering data. When MUSHclient is loading up a script file, is that accessing as read-only, or read/write?

See, above: CFile::modeRead | CFile::shareDenyWrite

That is read mode, but whilst open, you can't write to it. However it is only open for a few lines of code.

I am guessing there is a problem with a driver somewhere, that the "deny write" mode is persisting, when using a USB drive, and when the file is subsequently opened with LuaEdit, although I admit that sounds a bit strange.

Version 4.23 may fix this, as I took out the "deny write" when loading script files.

Sorry, I figured that through testing, the denial of writing would be removed. I should have specified that I was asking about the default action instead of when a user asks to deny the ability to write.


This is entirely possible. When editing files on a USB drive, most drivers will create a temporary cache of files to be written when you dismount the drive. I had this issue with an old USB writing method I used earlier, and I couldn't figure out why there wasn't data on the drive when I unmounted and rushed out the door with my usb drive. An odd flag could be set to lock the files out so that only the file in the temporary cache is accessed, not the one on the drive, but the driver is looking up the locked file on the drive for the reading. Eh, it could happen.

Resurrecting an old thread I guess...

calling Save("") from inside of OnPluginListChanged() gives me


DoAfterSpecial(.1, 'Save("")', sendto.script) works fine though.

I imagine the world file is still being read in, so trying to save it at that point is a bit premature.

Your proposed solution is probably the best way of dealing with it.

I have seen the same problem occur several times with version 4.86 of mushclient and Sublime Text 2, my favorite text editor. Has the issue been identified as to why yet? If so, I can put in suggestions to the appropriate devs to get this issue fixed between these two softwares, at least.

I met this issue with gnu emacs under windows, too.

Re-show it:
1. Only one world is open.
2. Script is lua, and, set "Recompile when script file changes" to "Always".
3. Use emacs to edit/save, after save, should popup sharing violation occurred.

When it happened, Menu Game/Reload Script File, Immediate, Reset All Timers, shows gray and can not clicked.

Well, change recompile from always to confirm/never, or use other editors, it should be OK.

I used 4.86. And also happened on 4.83, 4.85, 4.89.