Learn how easy it is to sync an existing GitHub or Google Code repo to a SourceForge project! See Demo

Close

#125 patch to configure file status checking

closed-accepted
Alan Ezust
None
5
2007-12-20
2007-08-06
Joe Walp
No

Attached is a patch to fix the following problem:

steps to reproduce:
1. Mount a remote filesystem across the internet [1].
2. Open several files from that location via jEdit
3. Move focus to an application other than jEdit
4. Move focus back to jEdit

actual behavior:
jEdit freezes for multiple seconds as the app checks file status for each buffer.

expected behavior:
Buffer should be editable immediately.

The patch adds a combo box to GlobalOptionPane that controls when jEdit checks file status. The new option reads:
=== prompt ==
Check for file change upon:

=== values ==
application focus
application focus, visiting the buffer or saving any buffer
visiting the buffer or saving any buffer
visiting or saving the buffer
saving the buffer

State for this configuration option is stored in a new integer property named 'checkFileStatus'.

The patch implements this new behavior.

In case you're curious, here's a short description of the use case satisfied by each option:

--- 1
Making 'application focus' the default option avoids introducing new overhead and retains behavior that plugins may expect. This option could be dropped if those goals aren't important.

--- 2
The 'application focus, visiting[...]' option is useful in an environment where multiple users may edit a file simultaneously.

--- 3
The 'visiting the buffer or saving any buffer' option defers notification of file changes until the user is at a natural pausing point in workflow.

--- 4
The 'visiting or saving the buffer' option deals well with many files where checking file attributes has high latency, such as in the sshfs-attached filesystem scenario that motivated this patch.

--- 5
The 'saving the buffer' option disables checking file attributes except during save and exit. This can be helpful when a network-attached filesystem is intermittently unavailable or unresponsive.

[1]
I use sshfs w/ compression enabled.
http://fuse.sourceforge.net/sshfs.html

Discussion

1 2 > >> (Page 1 of 2)
  • Joe Walp
    Joe Walp
    2007-08-06

    Logged In: YES
    user_id=1695195
    Originator: YES

    File Added: checkFileStatus.patch

     
  • Joe Walp
    Joe Walp
    2007-08-06

    Logged In: YES
    user_id=1695195
    Originator: YES

    File Added: checkFileStatus.patch

     
  • Logged In: YES
    user_id=285591
    Originator: NO

    Hi, I looked at your patch and there is something I don't like : The View.setBuffer(Buffer) cannot be removed and it should work as it works now so I suppose it should not check the file status. And you can add another setBuffer(Buffer, boolean) if you need it

     
  • Alan Ezust
    Alan Ezust
    2007-09-22

    Logged In: YES
    user_id=935841
    Originator: NO

    I just tried this patch. I like it in theory, but I'm not confident it works under all the cases it says it works, so it needs more testing.

    Here is my test case.

    General Options: Check for files changed upon: "visiting the buffer or saving any buffer".
    open file in sshfs mounted dir called "file1",
    open another file in same dir "file2"
    in an ssh window, I did "echo asdf >> file1"
    Went back into jedit. No check. So far so good.
    Switched buffer back to "file1". saw no notification of change, or the appended lines.
    Refresh manually. Then I saw the appended line.

    Then i removed the junk line and tried to save. At that point, jedit did a check and told me
    "file was changed on disk. reload?"

    Please make sure that test case works, I'll post others if I think of them.

     
  • Alan Ezust
    Alan Ezust
    2007-09-22

    Logged In: YES
    user_id=935841
    Originator: NO

    I just tried this patch. I like it in theory, but I'm not confident it works under all the cases it says it works, so it needs more testing.

    Here is my test case.

    General Options: Check for files changed upon: "visiting the buffer or saving any buffer".
    open file in sshfs mounted dir called "file1",
    open another file in same dir "file2"
    in an ssh window, I did "echo asdf >> file1"
    Went back into jedit. No check. So far so good.
    Switched buffer back to "file1". saw no notification of change, or the appended lines.
    Refresh manually. Then I saw the appended line.

    Then i removed the junk line and tried to save. At that point, jedit did a check and told me
    "file was changed on disk. reload?"

    Please make sure that test case works, I'll post others if I think of them.

     
  • Joe Walp
    Joe Walp
    2007-09-24

    Logged In: YES
    user_id=1695195
    Originator: YES

    ezust:

    I'm able to reproduce the behavior that you cite. But it appears to be an artifact of the sshfs filesystem. I see sshfs intermittently introducing delays. The first modification of file1 seems to be reported immediately. But the second modification isn't always. In my environment, the time between a second modification of file1 on the remote machine and seeing new file file size and timestamp via 'ls -l file1' on the local machine varies from 0 seconds to 12 seconds.

    I don't think this is fixable within jEdit code.

     
  • Joe Walp
    Joe Walp
    2007-09-24

    patch against svn trunk

     
    Attachments
  • Joe Walp
    Joe Walp
    2007-09-24

    Logged In: YES
    user_id=1695195
    Originator: YES

    kpouer:

    When the default option of 'application focus' is selected, setBuffer(buffer) behaves as it does in the current production release. It also behaves identically to the current production release when the 'saving the buffer' option is selected. Its behavior changes for the other three options. I've attached a new patch that makes this more obvious by renaming the new setBuffer parameter and changing its documentation.

    This behavior handles the case where a plugin calls setBuffer(buffer). When the user elects to have file status checked upon changing buffers, that check should occur regardless whether the buffer change is performed by the user or by a legacy plugin.
    File Added: checkFileStatus.patch

     
  • Alan Ezust
    Alan Ezust
    2007-10-05

    Logged In: YES
    user_id=935841
    Originator: NO

    joewalp: ok, I concede, this is probably a problem with sshfs.
    And since the first time I've used sshfs ever was to test your patch, I have no idea what the expected behavior is.
    I will continue testing this some more.

     
  • Alan Ezust
    Alan Ezust
    2007-10-05

    Logged In: YES
    user_id=935841
    Originator: NO

    joewalp: ok, I concede, this is probably a problem with sshfs.
    And since the first time I've used sshfs ever was to test your patch, I have no idea what the expected behavior is.
    I will continue testing this some more.

     
  • Alan Ezust
    Alan Ezust
    2007-10-06

    • assigned_to: nobody --> ezust
    • status: open --> closed-accepted
     
  • Alan Ezust
    Alan Ezust
    2007-10-06

    Logged In: YES
    user_id=935841
    Originator: NO

    committed to rev 10827. This will be in jedit 4.3pre12. Thanks!

    --alan

     
  • Joe Walp
    Joe Walp
    2007-10-08

    Logged In: YES
    user_id=1695195
    Originator: YES

    Cool. Nice working with you.

     
  • Joe Walp
    Joe Walp
    2007-10-08

    • status: closed-accepted --> open-accepted
     
  • Joe Walp
    Joe Walp
    2007-10-08

    Logged In: YES
    user_id=1695195
    Originator: YES

    Ug. It looks like I introduced a bug in that last version of the patch. Attached is the fix.

    To make behavior of the two setBuffer methods more clear (in response to kpouer's objection), I changed the new parameter of setBuffer from 'checkFileStatus' to 'disableFileStatusChecking'. This required changing boolean value for the second parameter of all calling routines. But somehow I missed the most important one, namely the setBuffer(buffer) implementation.

    Motivation for this what I stated in my 2007-09-24 04:59 comment. For example if checkFileStatus is configured to check upon buffer change, then when a legacy plugin such as SwitchBuffer calls view.setBuffer(buffer) this bugfix is required to make file status checking occur. Sorry for the hassle.
    File Added: checkFileStatusBugfix.patch

     
  • Joe Walp
    Joe Walp
    2007-10-08

    patch against svn trunk to fix setBuffer(buffer) bug

     
  • Alan Ezust
    Alan Ezust
    2007-10-09

    Logged In: YES
    user_id=935841
    Originator: NO

    ok I committed your change, and also updated the patched version currently on lazarus, in 4.3pre11, with that bugfix.
    ingemarh and others, please test it.

     
  • Alan Ezust
    Alan Ezust
    2007-10-09

    Logged In: YES
    user_id=935841
    Originator: NO

    ok I committed your change, and also updated the patched version currently on lazarus, in 4.3pre11, with that bugfix.
    ingemarh and others, please test it.

     
  • Alan Ezust
    Alan Ezust
    2007-10-13

    Logged In: YES
    user_id=935841
    Originator: NO

    I'm confused about something about this fix.
    "Check File Status" can mean two possible things. It could mean "check all buffers for changes" (CHECKA) or "check just THIS buffer for changes" (CHECKB)

    So the current behavior which is choice #1, means CHECKA when app gets focus.

    I think we need to be clear about what is happening when the other choices are selected, and document each of the cases a little better.

    If we leave jEdit, change FILEX, and refocus on a View that happens to be editing FILEX, shouldn't that be considered a "visit" to the buffer? I think it should do a CHECKB if someone is using one of the options that does not have the "Application focus" option.

     
  • Alan Ezust
    Alan Ezust
    2007-10-13

    Logged In: YES
    user_id=935841
    Originator: NO

    I'm confused about something about this fix.
    "Check File Status" can mean two possible things. It could mean "check all buffers for changes" (CHECKA) or "check just THIS buffer for changes" (CHECKB)

    So the current behavior which is choice #1, means CHECKA when app gets focus.

    I think we need to be clear about what is happening when the other choices are selected, and document each of the cases a little better.

    If we leave jEdit, change FILEX, and refocus on a View that happens to be editing FILEX, shouldn't that be considered a "visit" to the buffer? I think it should do a CHECKB if someone is using one of the options that does not have the "Application focus" option.

     
  • Logged In: YES
    user_id=238112
    Originator: NO

    I've now tried out the latest build from lazarus. From my understanding of the different options it doesn't work as expected. To me the term "visiting the buffer" tells me that whenever I switch from one buffer to another, jEdit should check the file on disk to see if it has changed since it was loaded into the editor or the last time it was saved. I did the following tests:
    - Loaded a.txt and b.txt in two buffers and stayed in buffer b.txt
    - Switched to another editor and loaded b.txt
    - Changed one char in the file and saved it
    - Switched back to jEdit. jEdit noticed that the file was changed since file b.txt was in the active buffer.
    - Switched buffer to a.txt and switched editor again
    - Changed another character in b.txt and switched back to jEdit
    - In jEdit I switched to buffer b.txt. I had expected jEdit to check the file on disk and notify me that the file had been modified. That didn't happen.
    - I updated one character in b.txt and saved the file. Here I also had expected jEdit to warn me which didn't happen and thus I effectively overwrote the previous changes done in the other editor.

    Another test:
    - Loaded a.txt in jEdit
    - Switched focus to a console window.
    - Issued "sleep 5; echo text >> a.txt
    - Within 5 seconds I switched back to jEdit (i.e. the file on disk didn't change before I switched back to jEdit), changed a character, waited 5 seconds and saved the file. Again I would have expected jEdit to warn me that the file was updated, which didn't happen, and again I overwrote the changes done outside jEdit

    The above described behavior goes for all options where "visiting" and "saving" are involved.

     
  • Joe Walp
    Joe Walp
    2007-10-14

    Logged In: YES
    user_id=1695195
    Originator: YES

    ingemarh:

    Whether you see a notification dialog depends on the settings for 'If open files are changed on disk' in both Global Options and Buffer Options. When both of these are set to 'automatically reload and notify user', I do see a notification dialog in both test cases that you describe.

    What are the Global and Buffer settings for 'If open files are changed on disk' during your tests? And are expecting a notification dialog or some other form of notification?

     
  • Logged In: YES
    user_id=238112
    Originator: NO

    I've always used 'Prompt' for the 'If open files are changed on disk' option.

    But now I've found something that maybe can help you track down the problem. I changed setting to 'automatically reload and notify user' in both settings and suddenly no updates whatsoever was performed, not even when I had the modified file in current buffer i jEdit when switching from the other editor to jEdit. Then I did some more option setting changes - more or less randomly - and suddenly everything worked as I expect it to do!!! I have 'Prompt' for the 'If open files are changed on disk' option in both Global and Buffer options. But it also works when I try the 'automatically reload and notify user' option.

    And now to the part that may help you.
    Then I renamed my personal settings directory (.jedit) in order to make jEdit start all over again. First I started the 'official' pre11 build just to get the settings directory initialized and then started the latest lazarus build.
    When I tried the settings 'Prompt' and 'visiting or saving the buffer' it worked as before, i.e. jEdit didn't prompt when I switched to a buffer with a file that was modified on disk. I then tried to recreate the behavior I encountered above, but now I can't get it to work as I expect, no matter how I switch back and forth between the different option settings.

    Just for completeness I did another turn and renamed the settings directory again, but this time I started the latest lazarus build from the beginning. No difference in behavior compared to when I started the 'official' pre11 build first.

    It shouldn't matter, but I'm using Windoze.

    Hope this helps!

     
1 2 > >> (Page 1 of 2)