Sharing violation problem with autosave?

Home Forums Multi-Edit Support Sharing violation problem with autosave?

Viewing 15 posts - 16 through 30 (of 43 total)
  • Author
    Posts
  • #5262
    Wayne Ostrowercha
    Participant

    I get the same problem with Linux sometimes.

    We have an old fileserver that provides an NFS file system for our Windows machines. I’ve noticed that sometimes it is very slow — say for example I copy a large directory from one location to the other; it may look like the directory was actually deleted for a minute or two.

    When using Multi-Edit, it sometimes cannot write to a file. There is a similar message to what you guys are reporting. But when I look in the NFS directory, there are a series of temp files created that contain the changes I was trying to save.

    I also get a similar problem with a java program I have as well. It can create a directory on this Linux fileserver but cannot always create a file on it. I think that it is related to this NFS filesystem, so it may not be a problem with Multi-Edit.

    #5263
    Clay Martin
    Keymaster

    main.css file size according to file manageer proporties 7855 bytes, 16384 bytes used.

    Can’t help with other questions.

    #5264
    Michal Vodicka
    Participant

    OK, it supports my partial load theory. Could you try it again and find out if file is partially loaded before error occurs? Negative test it possible: go to window with main.css file and jump to the file end. It’d cause complete load. Then check if error occurs again. If it is a reason, it might help to leave cursor at the file end and MEW should always load it completely.

    It’d be interesting to see the same log when error doesn’t occur and compare. Check if MEW closes main.css after open. I’d like to see it, too.

    #5270
    Clay Martin
    Keymaster

    Ok, opened mew, switched to file (main.css) used end key to go to bottom, made change to last line and ftp’ed – error occured. made another change, manualy saved, then ftp’ed, no error. All should be in the attached log.

    If I misunderstood your instructions let me know and I will try again.

    Because of upload limits I had to cut into 3 files, in order
    errlog.txt
    errlog1.txt
    errlog2.txt
    So look for 2 more posts after this one.
    errlog.txt

    #5271
    Clay Martin
    Keymaster
    #5272
    Clay Martin
    Keymaster
    #5290
    Michal Vodicka
    Participant

    OK, it is evident MEW “forgets” to close a file for some reason and later some other part can’t rename or delete it. The hard part is to find why the file isn’t closed after initial read (manual save probably forced close).

    Could you try to reproduce the situation when there is the error, let it in this state and run following macro WINDOW^WINOP /T=3/SYSTEM=1. It should display complete window list including system windows. In the list please find all instances of main.css file and see if they’re linked. I presume it will be loaded in a normal editing window and also in some system windows. When identified, display File | Properties for every instance, capture and post it here.

    To be clear: I’m interested in situation when MEW has opened main.css handle because it is what causes the error. Please check it using Process Explorer. It can be necessary to restart MEW to achieve this state.

    #5291
    Michal Vodicka
    Participant

    David,

    can you try the same as I described in previous post? Restart MEW, check if there is an opened handle to any of your sources and then examine windows.

    Do you use Preview pane?

    #5299
    David Morris
    Participant

    David,

    can you try the same as I described in previous post? Restart MEW, check if there is an opened handle to any of your sources and then examine windows.

    Do you use Preview pane?[/quote:39vd7sz9]
    Sorry Michael, been busy with other things and stepped away from the problem for a bit. I’ll try this out today.

    And yes, I do use the preview pane, although I can’t recall if it was previewing the file I was on or not when this happened. Now that you mention it, that would be good candidate for a file conflict, wouldn’t it? I do use tags quite a bit with the preview pane enabled, so clicking on a tag automatically loads the file in the preview window. That may well be the cause…

    #5301
    Michal Vodicka
    Participant

    David,

    yes, that’s why I mentioned it. The only good candidate for source file. For Clay’s .css files it’d be WebLair. I finally remembered when I saw it years before — I had error file loaded both in the edit window and in tool pane so I guess the conflict can occur when a file is loaded twice such a way. Just want to verify it.

    #5303
    David Morris
    Participant

    Okay Michael, I just played around with this and reproduced the problem. At first I couldn’t get the error to show when autosave fired, so I messed around with viewing several tags, then it happened.

    Here’s what I’ve done so far:
    [list:3hdl3g88][*:3hdl3g88] Reduced the auto-save timer to make it auto-save quicker[/*:m:3hdl3g88]
    [*:3hdl3g88] Selected a few tags for the current file, causing the file to load in the Preview pane[/*:m:3hdl3g88]
    [*:3hdl3g88] When the error happened, I left the error dialog on the screen and searched ProcessExplorer for any other process trying to load the file. MEW32 was the only one.[/*:m:3hdl3g88]
    [*:3hdl3g88] I dismissed both error dialogs and ran the macro to show all windows. The source file in question, CTFNC.C, was loaded twice as expected — once as a system file (presumably the Preview pane display). However they were not linked, or at least they didn’t have the little chain symbol visible if they were.[/*:m:3hdl3g88][/list:u:3hdl3g88]I didn’t run FileMon yet, I’ll go do that if it helps more, but I think we’ve narrowed down my problem to being a conflict with the Preview pane because until I started selecting tags I couldn’t get the problem to appear.

    #5305
    Michal Vodicka
    Participant

    Thanks, David. It is clear the error is caused by MEW itself; nothing else is involved. One file is loaded in two buffers (linked windows share one buffer) and I expect one of them is partially loaded. Could you check it? Select given window and display File | Properties.

    I’m still not sure what is the real bug. The fact there are two distinct buffers can be bad itself and sharing violation error can be good as it prevent problem when one buffer is saved and the other contains old data. Next possibility is opened handle; it isn’t normal situation even if file is partially loaded. At least for editing windows, maybe it is different for system ones.

    In any case, what you see with Preview pane is a symptom, not a problem itself. BTW, I believe it should be possible to avoid it using pre-save macro, if I’m correct about partial load.

    #5315
    Clay Martin
    Keymaster

    Ok,

    I did not get a failure right away so here is how it went

    Swiched to session with that file
    selected its tab, changed it, sent the file, No error
    changed it, sent the file, No error
    selected another file’s tab
    reselected the main.css file’s tab, changed it, sent it, got the Error
    Cleared the error popup
    Ran winop, main.css listed twice, not linked, one was system, selected non system copy and got properties

    Drive useage 7861 bytes
    Last mod 3/1/05 9:15:M
    Text in Memory 462
    The entire file is in memory

    ran winop again, selected the system main.css

    Drive useage 7861 bytes
    Last mod 3/1/05 9:14:M
    Text in Memory 200
    Not all the file is in memory

    One more thing, when I selected the system main.css it was indeed the preview pane.

    I’m unclear about what you want out of process explorer, as ME is the only process holding the file. Does PE provide other data that you would like?

    HTH
    Clay

    #5316
    Clay Martin
    Keymaster

    One more thing Michal,

    Had a thought. After fussing around trying to get the preview pane to go away and stay away I found the custom option “auto show preview pane for selected tools” and unchecked it.

    After that I was unable to recreate the problem.

    From the view menu selected the preview pane and then changed the file, sent it and got the error again.

    Since I don’t actualy use the preview pane, and can keep it from showing up, for me at least, problem solved. :wink:

    If you would like me to do any more testing just let me know.

    Thanks,
    Clay

    #5318
    Michal Vodicka
    Participant

    Thanks, Clay. It confirms what I expected — one file loaded in two distinct buffers. One buffer is partially loaded and keeps handle opened which blocks the second buffer save.

    Maybe I see where the problem is. Could you edit PreviewPane.s file, line 276 (or near) and change [code:3vm0qym3]xload_file( fn );[/code:3vm0qym3] to [code:3vm0qym3]Load_File(fn);[/code:3vm0qym3]
    Then exit MEW, recompile and relink MEW.MCL and try to reproduce problem.

    Code tries to avoid this situation and link Preview pane window to already loaded file if any. But there is a catch: it uses Switch_File() function which expects file names are equal including case. It can cause whole problem. Could you check File Properties again if main.css pathname differs in case? That’s probably why problem is so rare and I can’t reproduce it. Maybe you and David created tag database sometimes in the past and later changed case of some filenames.

Viewing 15 posts - 16 through 30 (of 43 total)
  • You must be logged in to reply to this topic.