Re: PLEASE FIX THIS ASAP!!!
I Thank-you.
Please provide us more details about your problem.
Before posting, please read how to report bug or request support effectively.
Bug reports without an attached log file are usually useless.
I Thank-you.
i don't fully understand how sftp work. been trying to find an easy explanation for a while but not found any.
since backgroud 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 sft-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
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 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.
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.
It is strange that WinSCP can even do that. It requires root permission and I don't provide the required ROOT credential.