Register forum user name Search FAQ

Gammon Forum

Notice: Any messages purporting to come from this site telling you that your password has expired, or that you need to verify your details, confirm your email, resolve issues, making threats, or asking for money, are spam. We do not email users with any such messages. If you have lost your password you can obtain a new one by using the password reset link.
 Entire forum ➜ MUSHclient ➜ Lua ➜ sharing violation occurred
sharing violation occurred

It is now over 60 days since the last post. This thread is closed.     Refresh page

Pages: 1 2  

Posted by Zylogia   (12 posts)  Bio
Date Sat 15 Mar 2008 10:24 AM (UTC)
Message
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.
Top
Posted by David Haley   USA  (3,881 posts)  Bio
Date Reply #1 on Sat 15 Mar 2008 11:39 AM (UTC)
Message
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.
David Haley aka Ksilyan
Head Programmer,
Legends of the Darkstone

http://david.the-haleys.org
Top
Posted by Nick Gammon   Australia  (23,120 posts)  Bio   Forum Administrator
Date Reply #2 on Sat 15 Mar 2008 08:44 PM (UTC)
Message
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:


   // open script file
    CFile fileScript (m_strScriptFilename, CFile::modeRead | CFile::shareDenyWrite);
   
    char * p = m_strScript.GetBuffer (fileScript.GetLength ());

    // read in the script
    fileScript.Read (p, fileScript.GetLength ());

    // m_strScript now contains the entire script file
    m_strScript.ReleaseBuffer (fileScript.GetLength ());

    // close the file in case they try to modify it
    fileScript.Close ();


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.
- Nick Gammon

www.gammon.com.au, www.mushclient.com
Top
Posted by Zylogia   (12 posts)  Bio
Date Reply #3 on Sun 16 Mar 2008 07:51 AM (UTC)
Message
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.
Top
Posted by Nick Gammon   Australia  (23,120 posts)  Bio   Forum Administrator
Date Reply #4 on Sun 16 Mar 2008 09:51 AM (UTC)
Message
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/

- Nick Gammon

www.gammon.com.au, www.mushclient.com
Top
Posted by Nick Gammon   Australia  (23,120 posts)  Bio   Forum Administrator
Date Reply #5 on Sun 16 Mar 2008 09:56 AM (UTC)
Message
Quote:

I was using LuaEdit because I wanted to see the syntax highlighting.


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.
- Nick Gammon

www.gammon.com.au, www.mushclient.com
Top
Posted by Zylogia   (12 posts)  Bio
Date Reply #6 on Sun 16 Mar 2008 03:35 PM (UTC)
Message
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.
Top
Posted by Shadowfyr   USA  (1,788 posts)  Bio
Date Reply #7 on Mon 17 Mar 2008 01:43 AM (UTC)
Message
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.
Top
Posted by David Haley   USA  (3,881 posts)  Bio
Date Reply #8 on Mon 17 Mar 2008 02:45 AM (UTC)
Message
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... :)
David Haley aka Ksilyan
Head Programmer,
Legends of the Darkstone

http://david.the-haleys.org
Top
Posted by Shaun Biggs   USA  (644 posts)  Bio
Date Reply #9 on Mon 17 Mar 2008 10:43 PM (UTC)
Message
Quote:
I am betting that the problem is that LuaEdit keeps the file open and locked

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?
It is much easier to fight for one's ideals than to live up to them.
Top
Posted by Nick Gammon   Australia  (23,120 posts)  Bio   Forum Administrator
Date Reply #10 on Mon 17 Mar 2008 11:24 PM (UTC)
Message
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.
- Nick Gammon

www.gammon.com.au, www.mushclient.com
Top
Posted by Nick Gammon   Australia  (23,120 posts)  Bio   Forum Administrator
Date Reply #11 on Tue 18 Mar 2008 06:21 AM (UTC)
Message
Version 4.23 may fix this, as I took out the "deny write" when loading script files.
- Nick Gammon

www.gammon.com.au, www.mushclient.com
Top
Posted by Shaun Biggs   USA  (644 posts)  Bio
Date Reply #12 on Tue 18 Mar 2008 08:14 PM (UTC)
Message
Quote:
See, above: CFile::modeRead | CFile::shareDenyWrite

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.

Quote:
I am guessing there is a problem with a driver somewhere, that the "deny write" mode is persisting, when using a USB drive

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.
It is much easier to fight for one's ideals than to live up to them.
Top
Posted by Fiendish   USA  (2,533 posts)  Bio   Global Moderator
Date Reply #13 on Mon 16 May 2011 06:19 AM (UTC)
Message
Resurrecting an old thread I guess...

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

A sharing violation occured while accessing
Z:\home\avi\Documents\aardwolfclientpackage\MUSHclient\worlds\Aardwolf.mcl.


DoAfterSpecial(.1, 'Save("")', sendto.script) works fine though.
https://github.com/fiendish/aardwolfclientpackage
Top
Posted by Nick Gammon   Australia  (23,120 posts)  Bio   Forum Administrator
Date Reply #14 on Mon 16 May 2011 07:32 AM (UTC)
Message
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.
- Nick Gammon

www.gammon.com.au, www.mushclient.com
Top

The dates and times for posts above are shown in Universal Co-ordinated Time (UTC).

To show them in your local time you can join the forum, and then set the 'time correction' field in your profile to the number of hours difference between your location and UTC time.

58,951 views.

This is page 1, subject is 2 pages long: 1 2  [Next page]

It is now over 60 days since the last post. This thread is closed.     Refresh page

Go to topic:           Search the forum

[Go to top] top

Information and images on this site are licensed under the Creative Commons Attribution 3.0 Australia License unless stated otherwise.

Home