Reply: Transfer Resume/Transfer to Temporary Filename

In reply to...

Transfer Resume/Transfer to Temporary Filename wrote:

Reasons not to do that:

• As the file is uploaded to a temporary name, it is technically a new file, even though the file with target name already exists. So after the original file is deleted and temporary file is renamed to the original file name, you loose all attributes of the original file (such as owner and group) except for permissions.

...yes, that's true, if you upload to a temp file, delete orig & move/rename temp file to orig file name, you WILL lose some file info/attribs.

So? Don't do that. Do this...

• Upload file with a temp name (file.tmp.part)
  
  Also, to counter...
  

  Transfer Resume/Transfer to Temporary Filename wrote:

  You may also need to disable the feature altogether, particularly if you do not have permissions required (e.g. permissions to create a new file in target directory).

  ...you could support uploading to /tmp or other "temp dir", instead or the real target dir.
• Set file times on file.tmp.part to match those on source
  
• Copy (not move or delete) file.tmp.part to file.orig (cp file.tmp.part file.orig) (this should preserve owner/group/perms, but not timestamps {which need updated anyway})
  
  I don't recommend cp -p (in this case), cuz I think that copies timestamps AND permissions, which we don't want.
• Copy timestamps: touch -r file.tmp.part file.orig
  
• Delete file.tmp.part (never delete file.orig, never lose owner/group)

...you could also do it this way...

• Upload file with a temp name (file.tmp.part)
  
• Copy (not move or delete) file.tmp.part to file.orig (cp file.tmp.part file.orig) (this should preserve owner/group/perms, but not timestamps {which need updated anyway})
  
• Set file times on file.orig to match those on source (never setting correct times on file.tmp.part)
  
• Delete file.tmp.part (never delete file.orig, never lose owner/group)

...those last 2 steps could even be done in the other way around, delete file.tmp.part, then set timestamps on file.orig.

I'm sorry, I may be missing your point, but I do not see any advantage of doing copy/delete instead of move. Actually I see only disadvantages.

Anyway, SFTP does not have copy operation, so there's no point discussing it.

About uploading to /tmp. There's no way to find out path to remote temp folder. Also the temp folder may be on completelly different filesystem than target folder, so moving the temp file may not be possible.

prikryl2 wrote:

...but I do not see any advantage of doing copy/delete instead of move.

...the advantage is that you don't lose owner/group, like is mentioned in the Docs. I didn't test this, I only went with what the docs said. They listed "Reasons not to do that"...so I came up with an alternative. I will gladly test this, providing Steps to Reproduce it both ways, the current behavior & the proposed behavior.

prikryl2 wrote:

Actually I see only disadvantages.

...could you list them?...I was trying to get around the current disadvantages (as mentioned in the Docs), I didn't think of any disadvantages to my way.

prikryl2 wrote:

Anyway, SFTP does not have copy operation, so there's no point discussing it.

...are there any docs, besides complicated RFCs, that list what each protocol can/can't do? Seems like "copy" would be an obvious operation it could do (why would someone invent a protocol without it???).

But in any case, my SFTP has SSH also, so it (anything the protocol can't do) could be done in an SSH session. Maybe you could support a new protocol "SSH/SFTP"?...(the implied combination of both at the same time)...selecting that as the "protocol" would tell WinSCP right away, that to do the "cool things" (which means anything that protocol {SFTP} can't do by itself {Copy}) it can immediately use SSH (it would start both sessions right at the beginning of WinSCP). Right now when I choose SFTP as the protocol, WinSCP limits all the functions it can do to what's in the SFTP protocol, ditto for SCP, never thinking to "break free" & use a separate SSH shell to do the things SFTP or SCP can't do. I think this is a really good idea, please ask if I wasn't clear enough in explaining what I mean. It should also not be much coding, most of this is already in WinSCP, just not connected logically. WinSCP can do SFTP & SCP & it can do "dumb SSH", in the sense of a non-TTY Terminal, but even that can do copy/move/delete/etc...things other protocols might not support. So why not combine those?...with "SSH/SFTP" & "SSH/SCP" protocol choices, I could give WinSCP permission to "break free" of any protocol limitations, by spawning its own SSH session to do the "dirty work". I can already spawn an SSH session & type the commands to do the dirty work, why not teach WinSCP how to do it itself?...WinSCP is a GUI, not a way to drop to the command line. Do you welcome help in coding?

prikryl2 wrote:

There's no way to find out path to remote temp folder.

...it could be user-specified. But also both Windows & Linux support the "set" command, by parsing the output, you could determine where the temp folder is.

prikryl2 wrote:

Also the temp folder may be on completelly different filesystem than target folder, so moving the temp file may not be possible.

...I don't understand this, mainly cuz I don't understand all the limitations of each protocol...but in SSH, I can move/copy from any "filesystem" to another.

Also, is "prikryl2" really "prikryl"?

...are there any docs, besides complicated RFCs, that list what each protocol can/can't do? Seems like "copy" would be an obvious operation it could do (why would someone invent a protocol without it???).

https://winscp.net/eng/docs/protocols

But in any case, my SFTP has SSH also, so it (anything the protocol can't do) could be done in an SSH session. Maybe you could support a new protocol "SSH/SFTP"?

There are loads of reasons why I wouldn't do this. And I'm sorry, I just do not have a time to list them here.

This basically answers all your other questiosn, as they all revolve around the SFTP/SSH idea.