If one inadvertently does a "self-connection" (i.e., from the client machine "mymachine" types "sftp mymachine"), logs in, and then "put foo", sftp transfers the file foo **leaving it empty** (0 bytes), therefore producing data loss. Maybe it is easier with an example: ++++++++++++++++++++++++++++++++++++++++++++ user@mymachine:~$ ls -l foo -rw-rw-r-- 1 user user 550 Nov 17 18:29 foo user@mymachine:~$ sftp mymachine Connecting to mymachine... user@mymachine's password: sftp> put foo Uploading foo to /home/user/foo foo 0% 0 0.0KB/s --:-- ETA sftp> quit user@mymachine:~$ ls -l foo -rw-rw-r-- 1 user user 0 Nov 17 18:30 foo +++++++++++++++++++++++++++++++++++++++++++++
How is this a bug??? It's like saying 'cp foo foo' is a bug. I guess the server side could write to a tmp file (like rsync would do), but severity seems like it should be trivial at best
writing to a temp file and doing an atomic replace changes the semantics on transfer a bit, but I am not sure it matters much. This certainly is not a critical bug.
Well, IMHO it *is* a critical bug since there is data loss (actually, I lost some critical info that luckily was partially backed up). Note that it is different from "cp foo foo" (in my case at least): cp complains that destination is the same as source and does nothing. It is also different from "scp foo mymachine:foo" since scp "copies" foo but leaves it untouched (not with 0 bytes as sftp does). I am reseting the severity back to "critical" for that reason, but I will accept your final word if you still think that I am wrong (and hence you revert it to "enhancement" again).
Also "cp foo foo" can check the inode numbers to see if they're the same file (or different hard links to the same file), whereas sftp can't. A better example would be "cat <foo >foo"; that'll trash the source file on most systems. Welcome to Unix. Writing to a tempfile and doing an atomic rename will mean that you will use up to twice the storage during the transfer, too.
wontfix - generally, it is impossible to detect this reliably. Just don't do it.
Change all RESOLVED bug to CLOSED with the exception of the ones fixed post-4.4.