I agree this looks like a bug.
Feel free to raise a JIRA and attach a patch !


2014-07-16 17:41 GMT+02:00 Mark Riordan <[email protected]>:

> I've encountered what I think is a bug in the Apache SSH server.  Before I
> submit a patch, I'd like to run this by the list in case I'm missing
> something.
>
>
> In short, read-only file opens succeed even if the file does not exist.
>  The subsequent file read commands are doomed to failure.
>
>
> In greater detail:
>
> SftpSubsystem.process() has a switch statement that processes commands.
>  File open processing is done by the SSH_FXP_OPEN case.  The code here
> succeeds even if file.doesExist() is false and the SSH_FXF_CREAT bit isn't
> set.  As a result, a handle is returned to the client as if everything were
> OK.  But when the client tries to do a SSH_FXP_READ on that handle, there
> will be no file that's actually open.  In this case, my application not
> unreasonably returns an error.
>
>
> The problem is that this works poorly with some clients - most notably the
> widely-used PSFTP.EXE.  What happens is that the client, seeing that the
> open succeeded, issues a large number of initial read requests, in order to
> optimize the flow of packets.  However, every one of these read requests
> fails.  And in my case, each results in a error record being logged in the
> application.  For PSFTP, that's 32 errors logged for each open of a
> non-existing file. For most other clients, the problem doesn't occur
> because they explicitly check for the existence of a file before trying to
> open it. However, PSFTP's behavior is perfectly reasonable.
>
>
> It seems to me that SftpSubsystem.process() should return an error if the
> file doesn't exist and the caller doesn't want to create the file.
>
>
> Any reason I shouldn't submit a patch?
>
>
> Thanks.
>
>
> Mark R
>
>
> I apologize that I erroneously submitted a similar question to the users
> mailing list, before I realized there was a separate list for developers.
>
>
>

Reply via email to