Bug 218307 - Uploaded file corrupted when two connections from same client uploading same file simultaneously
Uploaded file corrupted when two connections from same client uploading same ...
Product: Red Hat Enterprise Linux 3
Classification: Red Hat
Component: vsftpd (Show other bugs)
All Linux
medium Severity medium
: ---
: ---
Assigned To: Maros Barabas
: Regression
Depends On:
Blocks: 250727 392231 392251
  Show dependency treegraph
Reported: 2006-12-04 10:56 EST by Bastien Nocera
Modified: 2007-11-30 17:07 EST (History)
1 user (show)

See Also:
Fixed In Version: RHBA-2007-0425
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2007-06-11 14:44:33 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)
better rename patch (1.55 KB, patch)
2007-02-13 07:46 EST, Maros Barabas
no flags Details | Diff

External Trackers
Tracker ID Priority Status Summary Last Updated
Red Hat Product Errata RHBA-2007:0425 normal SHIPPED_LIVE vsftpd bug fix update 2007-06-07 15:25:00 EDT

  None (edit)
Description Bastien Nocera 2006-12-04 10:56:36 EST
Opened as a clone.

This bug is about a regression caused by the patch applied.

When 2 clients are uploading files, whether or not the file exists already, the
files are created with new unique names, instead of the original filename when
none exist.

+++ This bug was initially created as a clone of Bug #171308 +++

Description of problem:
I am using Redhat EL3 (AS) Taroon Update 5 with kernel 2.4.21-32.0.1.ELsmp. The
vsftpd.conf is in /etc/vsftpd and it is started by "service vsftpd start".

The vsftpd configuration is mostly in default settings. I have tested a number
some other vsftpd version (v1.2.2 rpm package for rh9), also encounter this
problem. I have also tuned some of the vsftpd configuratons such as "enable
chroot user", "enable ascii upload" etc and this bug is reproduced in all the

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

How reproducible:

Steps to Reproduce:
1.Launch 2 ftp connections to the ftp server
2.start uploading a file from both connections to the same destination folder
3.make sure both connections are transfering the same file simultaneously 

Actual Results:  the resulting upload will be corrupted with file size around
double of the orginal file

Expected Results:  A correct copy of upload from the most recent transfer (the
connection which ends later )

Additional info:

It seems that the two ftp transfer streams somehow merged due to the identical
file name.

-- Additional comment from rvokal@redhat.com on 2005-10-21 06:03 EST --
Created an attachment (id=120244)
rename patch for vsftpd-1.2.1

This patch renames the target file and overwrites the same file.. 

Would be great if you can test it and prove that it's correct.
Comment 1 Bastien Nocera 2006-12-04 10:58:30 EST

I looked through the patch that created the regression:

And it looks like the "uniqu-ification" of the filenames is done whether a file
with such a name exists or not.

On the server:
- install vsftpd
- start up vsftp
- create a test/test user

On the client:
- Launch twice the command:
lftp -e "put /tmp/rubbish/big-file"  -u test,test rhel5
with the line:
set net:limit-rate 1024
in your ~/.lftprc

On the server, during the upload:
~test/ # ls

Problem doesn't occur with RHEL4 or RHEL5.
Comment 2 RHEL Product and Program Management 2006-12-12 11:49:31 EST
This bugzilla has Keywords: Regression.  

Since no regressions are allowed between releases, 
it is also being proposed as a blocker for this release.  

Please resolve ASAP.
Comment 6 Maros Barabas 2007-02-13 07:46:50 EST
Created attachment 147984 [details]
better rename patch

Please test this patch (works for me) [but do not apply old one].
Comment 12 Red Hat Bugzilla 2007-06-11 14:44:33 EDT
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.

Comment 13 Issue Tracker 2007-06-13 07:09:20 EDT
Internal Status set to 'Resolved'
Status set to: Closed by Tech
Resolution set to: 'RHEL 3.9'

This event sent from IssueTracker by rkhadgar 
 issue 107951

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