FTP upload & overwrite does NOT overwite, but creates [file.ext].# instead
I have a very strange issue with FTP that is bugging the living daylights out of me. This is the FIRST time I have ever seen this issue.

When I upload a file, it does not overwrite the original, but instead gets renamed as [original file.ext].1 (or [file].2, if [file].1 already exists). For example, if style.css exist on the server, and I download and edit it, when I upload it back into position it gets “renamed” as **style.css.1**. Doing the attempt a second time produces a third file called **style.css.2**.

I own my own iron, upon which I have OpenSUSE 11.4 64-bit installed (a relatively recent install, just configured). I am making use of pure-ftpd and use the YAST control panel to manipulate the settings. The Umask (umask files:umask dirs) setting in particular is set to 000:000 (the only setting which will give an uploaded file the same permissions as existing files). I have Chrooted ftp access for everyone, and in order for FTP to access /srv/www/, I have used the instructions on [this site][1] to mount /srv/www/ inside /home/[user]/ftp/ using the bind operation. Ergo, FTP access is chrooted for a very secure user, but the user still has access to content within /srv/www/.

I have also taken the time to give the contents of /srv/www/ the same permissions and user:group as the user itself (i.e., there should be NO permissions issues).

I am using WS_FTP Pro 2007 to access the site, as well as Notepad++ (via NppFTP), and both clients have the same problem: I can download files just fine, but when I upload them they have “.#” appended to them (.1, .2, .3, etc.) instead of overwriting the original file. These new files have the IDENTICAL permissions and ownership (user:group) as the original file, so I am totally in the dark as to why the upload creates a new file instead of overwriting.



  [1]: http://www.ducea.com/2006/07/27/allowing-ftp-access-to-files-outside-the-home-directory-chroot/
FTP upload & overwrite does NOT overwite, but creates [file.ext].# instead
===

I have a very strange issue with FTP that is bugging the living daylights out of me. This is the FIRST time I have ever seen this issue.

When I upload a file, it does not overwrite the original, but instead gets renamed as [original file.ext].1 (or [file].2, if [file].1 already exists). For example, if style.css exist on the server, and I download and edit it, when I upload it back into position it gets “renamed” as **style.css.1**. Doing the attempt a second time produces a third file called **style.css.2**.

I own my own iron, upon which I have OpenSUSE 11.4 64-bit installed (a relatively recent install, just configured). I am making use of pure-ftpd and use the YAST control panel to manipulate the settings. The Umask (umask files:umask dirs) setting in particular is set to 000:000 (the only setting which will give an uploaded file the same permissions as existing files). I have Chrooted ftp access for everyone, and in order for FTP to access /srv/www/, I have used the instructions on [this site][1] to mount /srv/www/ inside /home/[user]/ftp/ using the bind operation. Ergo, FTP access is chrooted for a very secure user, but the user still has access to content within /srv/www/.

I have also taken the time to give the contents of /srv/www/ the same permissions and user:group as the user itself (i.e., there should be NO permissions issues).

I am using WS_FTP Pro 2007 to access the site, as well as Notepad++ (via NppFTP), and both clients have the same problem: I can download files just fine, but when I upload them they have “.#” appended to them (.1, .2, .3, etc.) instead of overwriting the original file. These new files have the IDENTICAL permissions and ownership (user:group) as the original file, so I am totally in the dark as to why the upload creates a new file instead of overwriting.



  [1]: http://www.ducea.com/2006/07/27/allowing-ftp-access-to-files-outside-the-home-directory-chroot/