When someone copies a file using scp in HP-UX 11.i Secure Shell (the HP
supported version of OpenSSH) and the destination file system hasn´t
enough space, a sparse file is being created. To reproduce the problem:

# bdf .
Filesystem          kbytes    used   avail %used Mounted on
/dev/vg00/lvol4    1015808  999189   15607   98% /old-opt 

Now copy over a large file like vmunix to show the problem, the
first scp works fine, the second will fail:

# scp  /stand/vmunix <machine>:/old-opt/mab/vmunix         
vmunix               100% |*****************************| 12027 KB    00:09  

# scp  /stand/vmunix <machine>:/old-opt/mab/vmunix2
vmunix               100% |*****************************| 12027 KB    00:08    
scp: /old-opt/mab/vmunix2: No space left on device

# ll
total 33238
-rwxr-xr-x   1 mab        wtec       12316048 Sep 24 18:20 vmunix*
-rwxr-xr-x   1 mab        wtec       12316048 Sep 24 18:21 vmunix2*
                                     ^^^^^^^^ <<<=== PROBLEM 

Now we can check for the real size:
# du *
24056   vmunix
9182    vmunix2 

I suspect that this problem is also present on other OS's, but at the moment, I
have confirmed it only on HP systems.

Running tusc on an "scp -t" process shows that ftruncate is being called no
matter what.

In sink() in file scp.c, we can see:

                if (ftruncate(ofd, size)) {
                        run_err("%s: truncate: %s", np, strerror(errno));
                        wrerr = DISPLAYED;
                }


This code fragment should be enclosed in this if condition:

              if(wrerr == NO){
                if (ftruncate(ofd, size)) {
                        run_err("%s: truncate: %s", np, strerror(errno));
                        wrerr = DISPLAYED;
                }
              }