Red Hat Bugzilla – Bug 218307
Uploaded file corrupted when two connections from same client uploading same file simultaneously
Last modified: 2007-11-30 17:07:10 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
+++ 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):
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 )
It seems that the two ftp transfer streams somehow merged due to the identical
-- Additional comment from firstname.lastname@example.org 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.
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.
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.
Created attachment 147984 [details]
better rename patch
Please test this patch (works for me) [but do not apply old one].
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.
Internal Status set to 'Resolved'
Status set to: Closed by Tech
Resolution set to: 'RHEL 3.9'
This event sent from IssueTracker by rkhadgar