I am having a strange issue with Internet Explorer, versions 7 and 8. I have our WebFM documents set up for viewing through links on a page, so basically the user would click and it takes them to a url set up like "http://www.domainexample.com/webfm_send/xxx". Some of my WebFM files open perfectly in IE7 and IE8, but others give the "file is corrupted and could not be repaired" error. However, this issue goes away completely if I am logged in to Drupal. Any guesses as to why that might be?

By the way, all links work perfectly in Firefox.

Comments

Foonaka’s picture

Foonaka commented

By the way, if I link to the file directly it works perfectly, as well. For instance, if I set the link URL to "/sites/default/files/documents/document-name.pdf" it opens with no issue whatsoever. So there is something that happens with WebFM after I click the HTML link that is stopping it from opening and produces the error. I guess it would mean that the document is not actually corrupted if it opens perfectly in IE when accessed outside of WebFM, right?

I just don't understand why it would work in WebFM when I'm logged in and not work when I am logged out.

cgmonroe’s picture

cgmonroe commented

Hmm, I'd say it was some files not being marked as "public" except you say it works in FF....

Does this problem occur with just specific file extensions or randomly? E.g., all .doc or .xxx files fail?

It might be how the mime types are set. You might try using Firebug to see what headers are being supplied on the file download.

Another possibility is that you're running into IE's "no-cache" bug. It interprets a "no-cache" header to mean "don't store this in the browser temp directory". So, suppose your accessing a Word doc and choose "open" as an option, IE downloads the file to temp, deletes it because of the no-cache header, then starts Word.. which can't find the file.

I'm assuming when you say "works when logged in" you are using the same webfm_send URL and not accessing it via the standard WebFM interface (they use different parts of the code).

Also, what Webfm rights does the logged in user have?

Finally, the direct URL will always work unless you've blocked access via a .htaccess rule. The difference is that the webfm_send URL goes thru the webfm security checks. If you're not big on security, having the files open is OK. But if security matters, you really need the .htaccess rule.

Foonaka’s picture

Foonaka commented
Status: Closed (fixed) » Active

First off, let me thank you for your response.

I am only using WebFM to manage PDF documents.

Basically I am only using it on the backend to upload and manage the documents. Since we have so many documents on many different pages, it makes it easier to keep track of which documents are where. On the frontend I am only providing the links, like you said, with the webfm_send URL.

I am not real big on security for the documents, so putting the full path to the document is not a problem, but using the webfm_send URL makes it much easier to enter the data.

I looked at the permissions issue. Logged in users (which are just administrators, since we don't have registered users) are allowed all permissions. I tweaked with the permissions for non-logged in users and nothing changed.

The caching issue you described has me curious, because it totally makes sense for what I'm dealing with.

Foonaka’s picture

Foonaka commented

I should also mention that I have the same problem in Safari for PC and Google Chrome.

cgmonroe’s picture

cgmonroe commented

I just tested all the files on that page IE7 and had not problems. I ran thru them using both the "Open" and "Save" options.

FYI - Windows XP/IE7 with latest patches and Acrobat 8 Professional.

Foonaka’s picture

Foonaka commented

That is really odd. A few minutes ago I tested that page on another machine with Win XP/IE7 and got the damaged file error on Open and Save. Incidentally, it also opened perfectly in Firefox on that machine.

I'm wondering what it is in other browsers (aside from Firefox) that is causing this to behave this way. This is very vexing!

Foonaka’s picture

Foonaka commented

I just took one of the "corrupted" files, changed the name, re-uploaded it and linked to the new file and it no longer gives me any issue. However, if I remove a file from the database, delete it, then re-upload it, it gives the same issue.

I'm wondering if there's something caching in the database that may be causing this?

EDIT---
This only worked on one file. Not sure why it's not working for others.

Foonaka’s picture

Foonaka commented

Just tried to delete a single file in the WebFM browser and it deleted the entire directory above it! After it did that, I simply clicked on another folder to open it and it deleted that entire folder, as well! I think I may need to find another solution.

dakotaryan’s picture

dakotaryan commented

Any luck figuring out while files are misbehaving in IE?

I'm having this same issue in IMCE on drupal 6 (that is, sometimes files are downloaded only partially and then will not open because they are "corrupted"). Any progress on this front?

Thanks, Dakota

cgmonroe’s picture

cgmonroe commented

Problems like this are hard to solve if you can't reproduce them. A couple of thought/things to check here:

The problem files might actually be error messages. Try doing a save as and then opening them with notepad or another text editor. Beware that actual binary files might display strangely.

It might be related to the headers being passed to the browser not matching the content. E.g., the file says it's a pdf but it's a doc or the Content-Length: header doesn't match the number of bytes being sent. The easiest way to get this is to use the GNU wget command (pretty standard on Unix/ available via Cygwin). It has an option to save the headers to a file.

Foonaka’s picture

Foonaka commented

I never did figure it out. I actually ended up scrapping the module, as much as I didn't want to, and just used CCK and Views to create a Document type and pull those documents into the correct node based on its Taxonomy term. So far it works pretty well, but on the other pages where we jus have miscellaneous document attachments it makes it much harder to track and sort documents. Wish it would have worked. I really liked this module when it was functioning properly for me. It was weird that it just started doing crazy things on its own.

nhck’s picture

nhck commented
Status: Active » Closed (fixed)

Sorry, but we couldn't reproduce your problem. Its very hard to reproduce something without follow up to the feedback.

Thank you anyway for trying to help.

James2010’s picture

James2010 commented
Status: Active » Closed (fixed)

I am getting the same problem in reverse. IE 6 works but FF 3.6.6 doesn't.

An .XLS sheet came through malformed, and a .PNG resulted in this error (in FF):
The image “http://drupal-dev.localnet/openatrium/content-g/webfm_send/2” cannot be displayed, because it contains errors.

I am using webfm-6.x-2.12 in OpenAtrium 1-0-beta7, which installed according to the README.txt with one exception: Workflow Settings > WEBFM ATTACHMENTS must be enabled at admin/content/node-type/book (or other type).

cgmonroe’s picture

cgmonroe commented

Often messages like this are the result of an error message being returned instead of the content. Some stuff to try is:

Check the logs for errors... especially PhP limits being exceeded (e.g. long execution, content too long, and the like).

Try saving the contents of the URL to a file (e.g. right click on a link/save as), then opening the file in a text editor. This may be a clean error message or have an error at the bottom of the file.

It's also possible that the file has changed (uploaded via FTP or other means) since it was upload. The file size is stored in the table and I think this is used in the headers when DLing a file. You might try deleting the file from the database and then re-adding it. I.e., as a WebFM Admin, right click and "remove from database" then use the add files in this directory icon to add it back in.

Note that you will loose any special file access privileges and meta data associated with this file when you do this.

FYI - Posting to a closed issue also means a lot of folks won't see it... the default is to only show open issues...