Post a reply

Before posting, please read how to report bug or request support effectively.

Bug reports without an attached log file are usually useless.

Options
Add an Attachment

If you do not want to add an Attachment to your Post, please leave the Fields blank.

(maximum 10 MB; please compress large files; only common media, archive, text and programming file formats are allowed)

Options

Topic review

martin

Re: workaround suggestion

@gabri.ns: Sorry, but I'm lost. What are "A" and "B"?
gabri.ns

Re: workaround suggestion

@martin: What about this?

  1. COPY A B
  2. RENAME A.partial
  3. RENAME B A
  4. TRUNCATE/RESUME A.partial
  5. DELETE A
  6. RENAME A.partial A

Is this operation primitive enough to be portable?

And i think this will also help catch this problem early on step 4
If the target file exists and it is not write-able, but the target directory is, the file will may be transferred anyway with automatic resume. The error overwriting the file will occur only after the transfer finishes. It is because the file is first transferred into temporary file.

And abort accordingly by reverting previous operation.
Guest

Still getting the error in 2018

It's really annoying cause it does it to seemingly random files, and the website I'm working on breaks on those files when the owner is no longer correct.
martin

Re: workaround suggestion

@gabri.ns: Thanks for your suggestion. Though that's not SFTP solution anymore. It's not portable.
gabri.ns

workaround suggestion

I don't fully understand how SFTP work. Been trying to find an easy explanation for a while but not found any.

Since background transfer is always opening new SSH connection, can you do it like this?

  1. open connection
  2. start SFTP server binary
  3. upload all queued file to temporary and keep a mapping of temp -> orig
  4. exit SFTP server
  5. use dd or cat to overwrite file, eg: cat temp > orig
  6. sleep. if there is new queue, go back to step 2
martin

Re: Thank you to have reported this bug

OK, I did not think very far when I wrote this extra point. Still for most files, the observed result is that the original (group) ownership is preserved. Only in special cases, the (group) ownership is changed. The documentation that you mentioned says nothing about (group) ownership. If we know about this other documented behavior, we can see the connection, but that does NOT make this special (group) ownership behavior a documented behavior. It is NOT a documented behavior, but if it was, I would consider this even worst. Who in is right mind would want such a behavior ?

It's not a desired behavior, but rather a side-effect of desired behavior.
I believe that both the side-effect and reason WinSCP does that (transfer via temporary directory) is well documented on page below (already linked earlier in this topic):
https://winscp.net/eng/docs/resume#automatic
Ricardo

It's a Unix/Linux limitation...

Quoting https://en.wikipedia.org/wiki/Chown :
Unprivileged (regular) users who wish to change the group of a file that they own may use chgrp.

For obvious security reasons, the ownership of a file may only be altered by a super-user. Similarly, only a member of a group can change a file's group ID to that group.
Guest

Re: Thank you to have reported this bug

@martin: OK, I understand that, if it deletes a file and creates a new one with the same name, WinSCP has no other choice than to use the logged-in user ownership. This is NOT documented, but it is an understandable behavior. However, in my case I was the owner and in the group of the original file in the server. Is there a reason why the group ownership is not preserved? At the end, I just want a simple uniform behavior, independent of other configurations and special file properties such as its size.
Guest

Re: Thank you to have reported this bug

@martin: OK, I did not think very far when I wrote this extra point. Still for most files, the observed result is that the original (group) ownership is preserved. Only in special cases, the (group) ownership is changed. The documentation that you mentioned says nothing about (group) ownership. If we know about this other documented behavior, we can see the connection, but that does NOT make this special (group) ownership behavior a documented behavior. It is NOT a documented behavior, but if it was, I would consider this even worst. Who in is right mind would want such a behavior ?
martin

Re: Thank you to have reported this bug

Dominic wrote:

It is strange that WinSCP can even do that. It requires root permission and I don't provide the required ROOT credential.

You do not need root permissions to delete a file and create new one with the same name, but an ownership of logged-in user.
Dominic

Thank you to have reported this bug

I had the same issue. My code would not work any more after some uploads. I noticed that the ownership of some files changed after every upload. I applied the work around and it does not do that anymore. Thanks. I don't give myself root permission, exactly because I do not want to mess with ownership. It is strange that WinSCP can even do that. It requires root permission and I don't provide the required ROOT credential.
Guest

The bug subject in the bugtracker item states that only Group is not preserved, but it is also the Owner that is not preserved. Both are equally important.
Guest

Also, the fact that file permissions ARE preserved, while group/owner aren't, qualifies this as a clear bug (not a documented behaviour).
Guest

Hi, Even though it is documented somewhere, the behavious is completely unexpected and dangerous as it creates severe security issues that are hard to notice. So thank you for creating a bug for it.

Regards,
pvalnov

[Security issue] Owner and Group are not preserved

Expected behaviour: If a remote file exists, and I upload or sync to the server a local file with same filename then the Owner and Group of the remote file should be preserved.

Actual behaviour: The expected behaviour is seen only for files that are under the size limit set in Transfer > Endurance > 'Enable transfer resume/transfer to temporary filename for'. Any files that exceed that size limit lose the original Owner and Group (they are not preserved). Interestingly, the original file permissions ARE preserved.

Workaround until this is fixed
:
Set Transfer > Endurance > 'Enable transfer resume/transfer to temporary filename for' to 'Disable'.

Tested with:

  • WinSCP 5.2.1 (Build 3231) and with older versions too (even 4.x.x) in SFTP-3 mode.
  • Remote server is Debian 6
  • Local server is Windows 7 SP1