Bug 218307

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
tests. 

Version-Release number of selected component (if applicable):
vsftpd-1.2.1-3E.1 

How reproducible:
Always

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 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.