[Home] [Downloads] [Search] [Help/forum]

Gammon Software Solutions forum

See www.mushclient.com/spam for dealing with forum spam. Please read the MUSHclient FAQ!

[Folder]  Entire forum
-> [Folder]  MUSHclient
. -> [Folder]  Lua
. . -> [Subject]  sharing violation occurred
Home  |  Users  |  Search  |  FAQ
Username:
Register forum user name
Password:
Forgotten password?
(New message)
Subject: sharing violation occurred
Name:
Your forum user name.
Register forum user name
Password:
Your forum password.
Forgotten password?
Message:
Message to be posted (in English, please).
Forum codes:
Check this if your message uses 'forum codes' or templates (auto-detected for new posts).
Forum codes Templates

Save this message ...

Subject review (reverse sequence)

Pages: 1 2  

Posted by Yanwuhuan   (11 posts)  [Biography] bio
Date Tue 12 Mar 2013 04:58 PM (UTC)  [ quote  ]

Amended on Tue 12 Mar 2013 05:15 PM (UTC) by Yanwuhuan

Message
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.
[Go to top] top
Posted by Damccull   USA  (7 posts)  [Biography] bio
Date Fri 18 Jan 2013 09:45 AM (UTC)  [ quote  ]
Message
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.
[Go to top] top
Posted by Nick Gammon   Australia  (18,770 posts)  [Biography] bio   Forum Administrator
Date Mon 16 May 2011 07:32 AM (UTC)  [ quote  ]
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
[Go to top] top
Posted by Fiendish   USA  (848 posts)  [Biography] bio   Global Moderator
Date Mon 16 May 2011 06:19 AM (UTC)  [ quote  ]
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.
http://aardwolfclientpackage.googlecode.com/
[Go to top] top
Posted by Shaun Biggs   USA  (644 posts)  [Biography] bio
Date Tue 18 Mar 2008 08:14 PM (UTC)  [ quote  ]
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.
[Go to top] top
Posted by Nick Gammon   Australia  (18,770 posts)  [Biography] bio   Forum Administrator
Date Tue 18 Mar 2008 06:21 AM (UTC)  [ quote  ]
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
[Go to top] top
Posted by Nick Gammon   Australia  (18,770 posts)  [Biography] bio   Forum Administrator
Date Mon 17 Mar 2008 11:24 PM (UTC)  [ quote  ]
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
[Go to top] top
Posted by Shaun Biggs   USA  (644 posts)  [Biography] bio
Date Mon 17 Mar 2008 10:43 PM (UTC)  [ quote  ]
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.
[Go to top] top
Posted by David Haley   USA  (3,881 posts)  [Biography] bio   Moderator
Date Mon 17 Mar 2008 02:45 AM (UTC)  [ quote  ]
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
[Go to top] top
Posted by Shadowfyr   USA  (1,774 posts)  [Biography] bio
Date Mon 17 Mar 2008 01:43 AM (UTC)  [ quote  ]
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.
main {
__if (Schrodinger_Cat is Alive or version >= "XP"){
____if version = "Vista" then Performance /= Number_of_Cores;
____call Functional_Code();}
__else
____call Crash_Windows();}
[Go to top] top
Posted by Zylogia   (12 posts)  [Biography] bio
Date Sun 16 Mar 2008 03:35 PM (UTC)  [ quote  ]
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.
[Go to top] top
Posted by Nick Gammon   Australia  (18,770 posts)  [Biography] bio   Forum Administrator
Date Sun 16 Mar 2008 09:56 AM (UTC)  [ quote  ]
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
[Go to top] top
Posted by Nick Gammon   Australia  (18,770 posts)  [Biography] bio   Forum Administrator
Date Sun 16 Mar 2008 09:51 AM (UTC)  [ quote  ]
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
[Go to top] top
Posted by Zylogia   (12 posts)  [Biography] bio
Date Sun 16 Mar 2008 07:51 AM (UTC)  [ quote  ]
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.
[Go to top] top
Posted by Nick Gammon   Australia  (18,770 posts)  [Biography] bio   Forum Administrator
Date Sat 15 Mar 2008 08:44 PM (UTC)  [ quote  ]
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
[Go to top] 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.

6,462 views.

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

[Reply to this subject]  Reply to this subject   [New subject]  Start a new subject   [Refresh] Refresh page

Go to topic:           Search the forum

[Go to top] top

[Home]

Written by Nick Gammon - 5K

Comments to: Gammon Software support
[RH click to get RSS URL] Forum RSS feed ( http://www.gammon.com.au/rss/forum.xml )

[Best viewed with any browser - 2K]    [Internet Contents Rating Association (ICRA) - 2K]    [Web site powered by FutureQuest.Net]