Hi,

I have problems with the file upload since the 1.6.4 update.
I’m bound to say, I replaced all files at the update and didn’t delete and reupload them.

1)
If there’s more than one dot in a filename, every additional dot becomes renamed to “._”.

23.06.2008-Assemblage-23-Blackfield-Festival-2008-Gelsenkirchen-01.jpg ->
23.06_.2008-Assemblage-23-Blackfield-Festival-2008-Gelsenkirchen-01_.jpg

la.la.lala-Assemblage-23-Blackfield-Festival-2008-Gelsenkirchen-01.jpg
la.la_.lala-Assemblage-23-Blackfield-Festival-2008-Gelsenkirchen-01_.jpg

la.la-lala-Assemblage-23-Blackfield-Festival-2008-Gelsenkirchen-01.jpg ->
la.la-lala-Assemblage-23-Blackfield-Festival-2008-Gelsenkirchen-01_.jpg

2) The file upload sets wrong permissions before the update it was 777, now its 644. Now you can’t replace files.

3) Just for information, because I can’t reproduce this, but a temp file was written in the file directory somehow
temp_file_04.07_.2008-Blackfield-Festival-2008-Logo_.jpg

1) This is not a bug, the first item is related to the bugfix in 1.6.3:

Increased security with uploaded file names to prevent Apache from overzealously parsing a file as a script.

2) And it should not be necessary to set permissions to 777 to allow PHP to overwrite files that it uploads, since it should be the owner of the file.  You’ll need to contact your host about this particular issue, as it would be caused by the server’s setup.  Using 777 there was a legacy fix from years past where on some server environments, files uploaded by PHP could not be modified via FTP.

3) The renaming occurs when there’s a filename collision, to allow the file to be uploaded.  Renaming or overwriting is then prompted for the next step, but if there’s an existing file with the same name that you are trying to upload, for that page request, we have to give it a temporary file name to allow it to proceed without automatically overwriting the existing file.

1) So I have to break with the existing naming convention, overwork old articles
- or -
using from now on unpractical ftp upload in the weblogs where this is happening?
So I have weblogs with file upload and weblogs with ftp upload.

This sounds like a lot of work and team training.
I’d rather like to switch off this security feature.

2) Ok I’ll ask the provider

ExpressionEngine’s code is certainly available for you to modify, but I cannot assist you in disabling security features, and highly recommend against this approach.  I understand the nuisance of having to modify an existing workflow, believe me, the fact that Apache behaves in a manner requiring this change is rather annoying, but out of our control.  In truth, this shouldn’t be too difficult to address with the team: a single email explaining the change you decide upon, say using hyphens instead of dots or something, and deciding whether it’s worth your time to go back through old files to rename them.

1) yeah… I’ll get over it.

2) My provider says, ee has to upload the files with the user “nobody” then file manipulation is possible for ee, and only for ee. File changes per FTP aren’t possible anymore.

EE doesn’t control what user PHP and Apache are running as, so that would be a change they would have to make.  The situation they describe is precisely what this old code was meant to work around, but in this day and age that’s extremely restrictive to have only one or the other.  Incidentally, many hosts such as EngineHosting run Apache as you, the shared hosting user, not only to keep things secure between accounts on the server, but to allow your scripts access to all the files your FTP user has.  There are other methods that have the same effect, but I would push my host to offer this; their competitors all do.

Hi Derek,

last word to 1) I replaced the old naming.

2)here’s the reply from Host Europe (http://www.hosteurope.de/)

Translation from German to English

—> Since PHP runs as a module and not as CGI, it is not possible to modify files with ftp and apache user simultaneously.

In general, the CMS should be capable to modify the files it applied, even with PHP as module.

Since your CMS creates the files with 644 “for security reasons”, you must try to change files with a tool like Quixplorer. A change of the file owner is not possible.

Original text

—>Da PHP als Modul und nicht als CGI läuft ist es nicht moeglich gleichzeitig mit ftp-user und apache die dateien zu verändern. Generell sollte das CMS aber in der Lage sein die von ihm angelegten Dateien zu verändern, auch mit PHP als Modul. Da Ihr CMS die Dateien “sicherheitshalber” mit 644 anlegt, müssen Sie dann versuchen mit einem Tool wie Quixplorer die Dateien zu verändern. Eine Änderung des Dateibesitzers ist jedoch nicht möglich. 

So, what can we do?

If they are unwilling to run their servers in a way that PHP runs as your user instead of apache, your decision would be whether the limitation of not being able to modify the files via FTP is worth shopping for a new host, or if using a workaround when needed such as with the tool their suggest is fine.  It’s really a matter of personal preference.