Bug 251565 - sftp problem while transferring files to a partition which is 100% full
Summary: sftp problem while transferring files to a partition which is 100% full
Alias: None
Product: Red Hat Enterprise Linux 5
Classification: Red Hat
Component: openssh
Version: 5.0
Hardware: All
OS: Linux
Target Milestone: ---
: ---
Assignee: Tomas Mraz
QA Contact: Brian Brock
Depends On:
TreeView+ depends on / blocked
Reported: 2007-08-09 19:11 UTC by Tomas Mraz
Modified: 2008-05-21 15:17 UTC (History)
2 users (show)

Clone Of:
Last Closed: 2008-05-21 15:17:08 UTC

Attachments (Terms of Use)

External Trackers
Tracker ID Priority Status Summary Last Updated
Red Hat Product Errata RHBA-2008:0341 normal SHIPPED_LIVE openssh bug fix update 2008-05-20 13:14:06 UTC

Description Tomas Mraz 2007-08-09 19:11:10 UTC
+++ This bug was initially created as a clone of Bug #247802 +++

Description of problem:
sftp problem when the partition is full. Not bailing out.

Version-Release number of selected component (if applicable):

1. Create a dummy partition /abc
2. Completely fill the partition /abc to 100%
3. In our application we are trying to sftp some files from /var/tmp [any
directory ] to /abc. The files are getting transferred to /abc with 0 bytes [ we
are trying batch mode ]. But the expected behaviour is that the sftp should bail
out when it finds partition full.

-- Additional comment from tmraz@redhat.com on 2007-08-07 16:33 EST --
Created an attachment (id=160853)
Proposed patch for sftp client

This patch fixes the inconsistency in sftp client behavior - with it sftp
always returns exit status 1 in batch mode when the write was not completely

Verification steps:

1, Create filesystem device and fill it up to 100%
   a, Have used my flash disk
      i, mkfs.ext3 /dev/sdb1
      ii, mount /dev/sdb1 /mnt/KINGSTON
      iii, stored some valid files + "dd" to ensure the 100% fullfilness of
           the device:

           dd if=/dev/zero of=/mnt/KINGSTON/nothing
           dd: writing `/mnt/KINGSTON/nothing': No space left on device
           8+0 records in
           7+0 records out
           7360512 bytes (7.4 MB) copied, 2.24142 seconds, 3.3 MB/s

2, Create ssh key-pairs to be able to use sftp batch mode
   a, # ssh-keygen -t dsa
      Generating public/private dsa key pair.
      Enter file in which to save the key (/root/.ssh/id_dsa):
      Enter passphrase (empty for no passphrase):
      Enter same passphrase again:
      Your identification has been saved in /root/.ssh/id_dsa.
      Your public key has been saved in /root/.ssh/id_dsa.pub.
      The key fingerprint is:
    b, Copied the "/root/.ssh/id_dsa.pub" key to the /root/.ssh/authorized_keys
       file of the destination machine so the root login without entering
       pwd would be possible

3, Created file "batch" with content:
   put oats.rpm /mnt/KINGSTON
   put oats_for_testing.rpm /mnt/KINGSTON
Old openssh packages (openssh-3.9p1-8.RHEL4.20.s390):

4, # sftp -b batch root@the_machine_with_precopied_public_key; echo $?
sftp> put oats.rpm /mnt/KINGSTON
Uploading oats.rpm to /mnt/KINGSTON/oats.rpm
Couldn't write to remote file "/mnt/KINGSTON/oats.rpm": Failure
sftp> put oats_for_testing.rpm /mnt/KINGSTON
Uploading oats_for_testing.rpm to /mnt/KINGSTON/oats_for_testing.rpm
Couldn't write to remote file "/mnt/KINGSTON/oats_for_testing.rpm": Failure

5, Both files "oats.rpm" and "oats_for_testing.rpm" with size "1" are 
   created on destination (remote_machine:/mnt/KINGSTON).

New openssh packages (openssh-3.9p1-8.RHEL4.24.s390):

1, Upgraded to new pkgs && restarted ssh
2, Removed files "oats.rpm" and "oats_for_testing.rpm" from /mnt/KINGSTON
3, Repeated command: 

   # sftp -b batch root@the_remote_machine_with_precopied_public_key; echo $?
   sftp> put oats.rpm /mnt/KINGSTON
   Uploading oats.rpm to /mnt/KINGSTON/oats.rpm
   Couldn't write to remote file "/mnt/KINGSTON/oats.rpm": Failure
4, This time sftp bails out the connection after the first one unsuccessful
   attempt to transmit a file and returns error code.
5, The first file with "oats.rpm" with size of "1" is created on
   the destination /mnt/KINGSTON.

Comment 1 Tomas Mraz 2007-08-09 19:33:19 UTC
We should fix this for RHEL 5.2 as the bug will be fixed in RHEL 4.6.

Comment 2 RHEL Product and Program Management 2007-10-16 03:49:42 UTC
This request was evaluated by Red Hat Product Management for inclusion in a Red
Hat Enterprise Linux maintenance release.  Product Management has requested
further review of this request by Red Hat Engineering, for potential
inclusion in a Red Hat Enterprise Linux Update release for currently deployed
products.  This request is not yet committed for inclusion in an Update

Comment 7 errata-xmlrpc 2008-05-21 15:17:08 UTC
An advisory has been issued which should help the problem
described in this bug report. This report is therefore being
closed with a resolution of ERRATA. For more information
on the solution and/or where to find the updated files,
please follow the link below. You may reopen this bug report
if the solution does not work for you.


Note You need to log in before you can comment on or make changes to this bug.