Subject: end-of-list in SSH_FXP_NAME

From: denis bider <[email-masked]>
Date: Thu, 8 Dec 2005 01:46:41 +0100

Hi folks,

for the end-of-list field in SSH_FXP_NAME, the draft says: "This field is optional. If present in the packet, it MUST be true."

I think this is, well, stupid. (?) Without this requirement, SSH_FXP_NAME could be extended in the future with extra fields that older implementations would ignore. But *with* this requirement, the packet is not extensible, because now you can't add anything new to the end of the packet without also including end-of-list, which "MUST be true".

It seems to me that there would be no harm in letting the end-of-list flag be false. It would allow room for future extension if necessary.

Best regards,

denis

---

From: Joseph Galbraith <[email-masked]>
Date: Wed, 07 Dec 2005 19:32:21 -0700

denis bider wrote:
> Hi folks,
> 
> for the end-of-list field in SSH_FXP_NAME, the draft says:
> "This field is optional. If present in the packet, it MUST be
> true."
> 
> I think this is, well, stupid. (?) Without this requirement,
> SSH_FXP_NAME could be extended in the future with extra fields
> that older implementations would ignore. But *with* this
> requirement, the packet is not extensible, because now you
> can't add anything new to the end of the packet without also
> including end-of-list, which "MUST be true".
> 
> It seems to me that there would be no harm in letting the
> end-of-list flag be false. It would allow room for future
> extension if necessary.

Good point.  I'll change that.

Thanks,

Joseph

---

From: denis bider <[email-masked]>
Date: Fri, 9 Dec 2005 00:01:45 +0100

One other thing.

I think the SFTP protocol is seriously missing a way to copy data on the server without having to download it to the client and upload it back to the server.

At the very least, I think there needs to be a copy request that will make a straightforward copy of file A to file B, with some very basic flags such as whether to overwrite when file B is already present.

A close second requirement is for an ability to concatenate files.

We can go at this in multiple ways. One would be to provide separate requests for each type of copy or append that we can envision.

However, how about we provide a way to instruct the server to copy data between two open file handles?

This could be a request such as the following:

  SSH_FXP_COPY
  uint32 request-id
  string read-from-handle
  string write-to-handle
  uint64 read-from-offset
  uint64 read-from-length
  uint64 write-to-offset

That's all that is needed.

Now the client can open the source file, open or create the target file, and copy data without having to download it in a gazillion separate packets and upload it back to the server.

How does that sound?

Best regards!

denis