[ 
https://issues.apache.org/jira/browse/SSHD-903?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16781408#comment-16781408
 ] 

Mark Ebbers commented on SSHD-903:
----------------------------------

{quote}Here is what {{fysnc}} issue is (in a nutshell...) - when one 
creates/updates a file via the Java API the file contents are not immediately 
sync-ed with the file system. This means that if another process attempts to 
access the file within a short time (how short I cannot tell) from when it was 
updated it may still get old data. In other words, unless one explicitly cause 
the {{fsync}} (there are several ways to do this in java) the file will 
*eventually* be sync-ed (maybe a few seconds) - but until then, external 
processes need to wait enough time before accessing the updated/created file.
{quote}
The file will also be corrupt after a while. I have the feeling that the last 
SSH packet of that file transfer is written to disk at the wrong offset. (A 
corrupt file is always size - size_last_packet). The strange thing is that I 
cannot reproduce it on my machine locally (using the same version of our SFTP 
server with the same MINA/SSHD library version & SFTPv6, but local filesystem) 
but 9 of 10 files are corrupt if I test it over the (local) network (this 
server uses glusterfs). With SFTPv3 everything works ok. So it can also be a 
problem in the combination of SFTPv6 + gluster or SFTPv6 + network. Is the 
method of writing files to disk different in the SFTPv3 or SFTPv6 
implementation? (async?)

If I have more time I will try to dive deeper in this problem. 

> SFTP version negotiation does not work  
> ----------------------------------------
>
>                 Key: SSHD-903
>                 URL: https://issues.apache.org/jira/browse/SSHD-903
>             Project: MINA SSHD
>          Issue Type: Bug
>    Affects Versions: 2.2.0
>            Reporter: Mark Ebbers
>            Assignee: Goldstein Lyor
>            Priority: Major
>             Fix For: 2.3.0
>
>         Attachments: screenshot-winscp-sftp-version.png, sftp-version-1.png, 
> sftp-version-2.png, winscp-info.png, winscp.png
>
>          Time Spent: 20m
>  Remaining Estimate: 0h
>
> I have some problems with uploading files to our MINA SSHD based SFTP server 
> when using ,different version, of WinSCP as SFTP client. WinSCP is configured 
> to use version 6 of the SFTP protocol if possible. 
> Uploading a file of ~ 45KB sometimes result in a file of 32711 bytes where in 
> the data is not appended (from the second SFTP packet) but overwritten. (But 
> did not pin point the exact bug)
> As a temporary solution I found, in issue SSHD-874, a comment which suggest 
> to force the server to use sftp-protocol version 3. If I do this I expect the 
> server to negotiate with the client that version 3 should be used instead of 
> version 6. But what happens is that the server sends a not supported message.
>  
> I think that the AbstractSftpSubsystemHelper::checkVersionCompatibility() is 
> the problem.
> See my screenshots. As you can see the version proposed by WinSCP is version 
> 6. I forced the server on version 3.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

Reply via email to