I experience many problems since I use FTP plugin 1.3.1
Exception occurs while saving file to remote server and then file cannot be saved to server.
I open file from ProjectViewer, with project base path like: sftp://myremoteserver/my/dir/
The edited file has its address like: sftp://@myremoteserver/my/dir/file.ext
I experienced these exceptions really often: impossible to edit a file with jEdit on a remote server, each time I restart jEdit, only one save is possible. Other attempts to save lead to exception.
I also experience ConcurrentModificationException when reloading a file (e.g. pressing twice the reload button).
If you do not supply a username, then SFTP plugin looks for a connection described by your hostname in the "config" file. Do you have a config file that defines what that server is supposed to point to? If not, supplying a username might solve your problem.
Yes, I use a ssh config file. And the error occurs after I load the file at least once. Sometimes, the file gets saved correctly, but it generally fails on second or third time.
It is also impossible to edit the file until the save operation is done (which never appends).
I tried using the 1.3 version, but the error is also there.
I also notice that there is no task in the IO/monitor. It seems like threads do not manage correctly concurrent accesses.
Ticket moved from /p/jedit/plugin-feature-requests/362/
So just to confirm, this problem is only related to ProjectViewer integration? I am unable to see this problem using the file system browser.
Yes, disabling project viewer seems to remove the problem.
When enabled, I have java.util.ConcurrentModificationException which occurs. After this exception is thrown, impossible to make further save to the server.
Hi,
A new update:
FTP works well using ProjectViewer now. When I disabled it, it also disabled other plugins "Make" and "Git Plugin"
I re-activated ProjectViewer without the two plugins which depend on it.
I suspect these two plugins (or one of them) to cause the problem.
I can't reproduce your problem on my particular ssh server.
You report you have a workaround, that is good to hear.
Hi again,
Sorry, but the bug seems to re-appear, although the two plugins (Make and Git Plugin) are still disabled.
I think it is due to my network quality: sometimes I experience short disconnections. I think they cause the problem I have: impossible to save the file anymore. Closing the file and re-opening it allows to save it again (without closing JEdit)
It looks like there is a disconnection, but on another server (for another file I am editing):
I checked my Saving and backup options since I also found this warning:
I had enabled in Global Options > jEdit > Saving & Backup:
Two-stage save
Backup on every save
* Backup directory is left empty
But I think the problem comes from the fact I open files on TWO different servers. In the log I attach, I experience a "Disconnecting from nas.local port 64001" (line 7957) which causes a lot of exceptions. And just after that, I cannot save the currently edited file anymore on my other server.
I suspect these exception to let the program in a state that do not allow to save file.
I also notice that there is that '@' character just after the "sftp://" that sometimes appear.
So I understand that you cannot reproduce this, but I am still annoyed by this.
Try specifying a backup directory and see if the problem goes away.
I set the backup directory this morning. Same error just occured once again.
I did the following just before the error:
1. save the file
2. edit the file
3. save again before previous save task has finished.
But trying to reproduce the previous procedure does not lead to the error.
So the thread is left in inconsistent state because of something else.
Each time I try to save again, I have the error shown in the attached image, but nothing in task monitor. And still impossible to modify the text of the file.
I think it is one of those worst bugs: the one that works on many times, but fails just sometimes.
Last edit: lauhub 2016-02-07
Today, I experience a lot of problems of the same type.
17:10:12 [Connect thread servername.net session] [message] SftpLogger: Caught an exception, leaving main loop due to Read timed out
17:10:12 [Connect thread servername.net session] [message] SftpLogger: Disconnecting from servername.net port 22
I disabled backup: same problems.
I always that error: Each buffer can only execute one input/output operation at time...
But there is nothing in the Task Monitor.
Did you try to reproducte this ? I suggest you to try to save a file and to disconnect your network at that moment. I think this is a network problem that is not correctly managed by the plugin.
I identified an issue in the FTP source code.
In FtpVFS.java, in method
_getFile
at line 330, the path is compared to the toString value of the FtpAddress address object.Actually, this toString method will return
sftp://@...
if user is not null. Since user could be""
(an empty string), this could lead to a confusion :sftp://@myremoteserver/my/dir/file.ext
is then not the same assftp://myremoteserver/my/dir/file.ext
.I think this can confuse the ProjectViewer plugin, and also lead to the ConcurrentModificationException (its trace contains ftp.FtpVFS._getFile).
Last edit: lauhub 2016-02-18
ok, I fixed the toString() method, and I updated the version of FTP.jar on dropbox.
Does that fix your issues?
https://www.dropbox.com/s/55jlinf5cxg2z9v/FTP.jar?dl=0
OK thanks a lot.
Some more information about this bug. Using Eclipse to try to find out what was going on, I made several observations:
io
parameter from the org.gjt.sp.jedit.buffer.JEditBuffer is set totrue
at each saveio
parameter is not always correctly reset tofalse
. If I set it (using the debugger) tofalse
(when I experience the bug and cannot save anymore), and then save again, the problem is solved for some time.io
is not correctly reset. Could not find any exception that is thrown or anything else. But...catch(java.lang.InterruptedException e){};
(line 1253).JSch.getLogger().log(Logger.INFO, "Caught an exception, leaving main loop due to " + e.getMessage());
io
parameter not reset because of an exception was not processed. But it is only a supposition.I intensively use the FTP plugin for now, and the bug only appears 5 times out of 100 (it depends on something I cannot understand). So I will let you know if it was linked to the
toString()
method behaviour or not.Some news (not good I am afraid) :(
Hope one day I'll come with good ones for you :)
I experience strange behaviours since your last update.
Some buffers cannot be closed anymore. They match with an existing remote file, but are empty. Impossible to close them. I can add text, save as a new file (to avoir erase good file). But impossible to close : I have a stack trace with a NullPointerException (see attached file)
Other unexpected behaviour: some executable files become non executable when saving. I need to chmod them. But not everytime: sometimes it just works fine and save properly without permission change.
I'll investigate. Is the svn repository up-to-date ?
Last edit: lauhub 2016-02-19
If you find other issues in our code, let me know. It seems your recent discussion should go on the jsch-users@lists.sourceforge.net mailing list.
The SVN repo is up to date for the FTP plugin.
Last edit: Alan Ezust 2016-02-19
If you find the permissions are reset by saving, you might want to switch off "two-stage save" from global options - saving and backup. That is completely unrelated to this ticket.
Looking at the null pointer exception.log, it seems to be related to whether you have some text selected or not! Very strange, and perhaps a bug in jEdit itself.
You could add a null-check for the "Selection s = selection[i]" in line 420 of EditPane.java and see if that helps. I have no clue why it might be null there.
Last edit: Alan Ezust 2016-02-19
Ok, after some testing, it appears that the bug is still here.
Reseting
io
attribute with the debugger is the only way to make save possible.I also have these two messages:
Why is
connect
set tonull
there ? I suppose it should not. I will try to investigate this and find when I reach this case.How do I reproduce this issue? Is it really the same issue as the one that is in the initial description of this ticket? If not, perhaps this ticket should be closed and a new one opened with a more descriptive title and steps to reproduce.