Attach File Fails (missing /usr/bin/file)
Attach File Fails (missing /usr/bin/file)
| Issue ID: | 1787 |
| Issue Category: | bug |
| Component: | core |
| Priority: | critical |
| Status: | invalid |
| Assigned: | Unassigned |
| Version: | 0.8 |
| Milestone: | 0.8 |
| Keywords: | /usr/bin/file, attachments, filecommand, fileinfo, file_info |
Site http://blurbi.com is running Laconica 0.8.0 installed on GoDaddy Linux hosting with PHP 5.2.5 support. File attachment fails. Error message logged is, PEAR error: Can't find file command "/usr/bin/file".
I assigned 777 permissions to directory \file\ for receiving the files, but this did not help.
Debug mode revealed no helpful warnings or errors.
MIME types, file size, and other quota parameters are left deferred to defaults in lib/common.php - config.php is unaltered, the relevant section remains commented out.
I tested attachment two different ways: (1) without a message and (2) with a message. Please see the attached screenshots of the behavior displayed in IE 8 and Chrome 2. Note the "C:\fakepath\" prepended to the file in question in IE 8, but not prepended in Chrome 2, when no message accompanies attachment. The Send button, upon clicking, does not show animation, but in both browsers the character counter receives an odd background surrounding it. Nothing else happens.
When a message is included, and Send is clicked, button animation is invoked, but there is still no success. The message "New notice" is displayed below the entry form, but the personal and public timelines show that the notice has not posted, and the file has not uploaded, not attached.
Updates
#1
What methodology works for the avatar upload and attach facility that does not or is not applied to generic file attachments? Is MIME detection a necessarily serialized process for attachments, or can it be a safely failing parallel, non-dependent process?
#2
The user-agent decided whether to prepend the path to file or not.
Chromium on Ubuntu attaches files okay. I'll test IE8 and Chrome 2 at a later date.
Please make sure to pull latest from 0.8.x.
#3
Thanks for looking into this.
Did the Chromium client on Ubuntu invoke some alternate fileinfo functionality from blurbi.com's laconica installation so that the inaccessible /usr/bin/file on GoDaddy's Linux host was not involved?
#4
The file type check only seems to be applied to attachments (in actions/newnotice.php from the web UI and again over in scripts/maildaemon.php for mail commands). It's not done for avatar uploads, which run through a totally different path.
Note that if you do have the standard 'file' command but in a different path, you can override $config['attachments']['filecommand'] in config.php and it should use it.
Some possible improvements...
1) Encapsulate the file type check (so we don't duplicate this code in UI and mail daemon paths)
2) Check for the error return from the mime type module and handle gracefully...
3) Fallback to fileinfo PHP module (default in 5.3.0 and later)
4) Fallback to getfilesize() which gives common image types
5) Optionally, fallback to some manual type magic checks (eg MediaWiki's code for validating XML and zip-based OpenOffice types)
#5
I have file command set up, "which file" gave /usr/bin/file (good permissions), I tried in firefox 3.5.3, and midori on arch linux running postgresql, apache and lighttpd, no luck. Same error. Only, in my case there are two error messages logged:
2009-10-14 16:03:35 LOG_ERR: PEAR error: Can't find file command "/usr/bin/file"
2009-10-14 16:03:35 LOG_ERR: ServerErrorAction: 500 An important error occured, probably related to email setup. Check logfiles for more info..
I can upload only png avatars. JPEG breaks it saying "gd-jpeg: JPEG library reports unrecoverable error: in /var/www/st/lib/imagefile.php on line 139" which is really out of context of this bug, but it is proof that i can upload files.
(I've tried uploading many times and both messages turn up)
And no, it's got nothing to do with GoDaddy in my opinion.
Is there a workaround for now? I really need this going.
I tried the latest mainline code too, same error.
#6
Ok got some phpinfo() output from g0... yeah, looks like it's the open_basedir setting:
open_basedir /srv/http/:/home/:/tmp/:/usr/share/pear/:/var/www/
Since /usr/bin isn't in the open_basedir directory whitelist, the PHP-based code can't check to confirm that /usr/bin/file is present, and it's spitting back the error. Our code then craps out because it doesn't handle that case.
A fallback to getimagesize() should resolve this at least for standard image formats.
#7
[http://www.4insure.net/ Auto Insurance]
#8
Dont know why htyuan changed the owner to me, putting it back to csarven
#9
You can also subscribe to the
RSS feed for updates to this issue.