Closed Bug 219730 Opened 21 years ago Closed 21 years ago

download of PDF file mysteriously fails

Categories

(Core Graveyard :: File Handling, defect)

Product:
Core Graveyard
Component:
File Handling
Platform:
PowerPC
macOS
Type:
defect
Priority:
Not set
Severity:
major

Tracking

(Not tracked)

Status:
RESOLVED DUPLICATE of bug 166369

People

(Reporter: lorenrosen, Unassigned)

References

(
URL
)

Details

(Keywords: helpwanted)

User-Agent: Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.5) Gecko/20030916 Build Identifier: Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.5) Gecko/20030916 I have a specific preferences entries for PDF files, directing Mozilla to use Acrobat reader. Works fine in 1.4 and earlier releases. In 1.5, it downloads the file and then mysteriously fails at the end. Reproducible: Always Steps to Reproduce: 1. enter above URL for pdf file into location box, hit return (or visit http://www.lacie.com/products/product.htm?id=10022, and click on the "datasheet" link) (though I don't believe there's anything special about this particlar page or link) 2. download will proceed 3. when the download is finished Mozilla bring's up a error dialog saying "... could not be saved, because an unknown error occured. Sorry about that. Try saving to a different location" Actual Results: Helper application was no invoked. Mozilla even deleted the downloaded file. Note that using the contextual menu and "save this link target as..." does work. Also, everything worked fine with Mozilla 1.4 Expected Results: saved file, invoked helper application running MacOS X 10.1.5
OK. Can you, using tomorrow's nightly build, create a helperappservice log and attach it to this bug? please do make sure that you create it using build 2003092404 or later. (For how to do it, see http://www.mozilla.org/projects/netlib/http/http-debugging.html, but replace nsHttp:5,nsSocketTransport:5 with HelperAppService:3)
Here's the result from the appservice log: -2147478600[293b70]: HelperAppService::DoContent: mime 'application/pdf', extens ion 'pdf' -2147478600[293b70]: Getting mimeinfo from type 'application/pdf' ext 'pdf' -2147478600[293b70]: OS gave back 0x3d8d990 -2147478600[293b70]: Data source: Via type 0x3ad7130 -2147478600[293b70]: Extension 'pdf' matches mime info: 'yes' -2147478600[293b70]: Type/Ext lookup found 0x3d8d990 -2147478600[293b70]: Error: writeError, listener=0x3ad5404, rv=0x80520008
-2147478600[293b70]: Error: writeError, listener=0x3ad5404, rv=0x80520008 hm... this means NS_ERROR_FILE_ALREADY_EXISTS. the only way I can possibly see that happen would be for the MoveFile call. But the api specifies that it should replace files, the code both in nsLocalFileOSX and exthandler makes sure that the target file is deleted before the file is renamed. bz, any ideas?
Not offhand. ccing some people who may have an idea about nsLocalFileOSX
cc:'ing someone who knows nsLoaclFileOSX even better
This really needs someone with a Mac to look at it... :(
Keywords: helpwanted
I bet this was bug 215089 or is bug 166369
Depends on: 166369
This is still happening on OSX 10.3! I can have it download for 15 or 20 minutes and then FAIL AT THE VERY END! This should be a high priority fix! The annoying thing is that it must have the data already! So how about popping up a window to save it? It is STUPID to force the user to reload it!
Tom Schneider, thank you for failing to mention important details like what build of Mozilla you are using. Please do give bug 166369 a read, because I bet that's what you're seeing.
Boris: Thank you for your kind and thoughtful words. Mozilla 1.5 Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.5) Gecko/20031007 OSX 10.3 My error occurs with pdfs, not other downloads. The one that this happened for was (probably) the first PDF on http://www.sciserv.org/sts/documents/ (if it was not the first, it was the second.)
Tom, what's the helper listed for PDF in your helper app preferences?
Mozilla, preferences, Helper Applications, edit: MIME Type; application/pdf Description: Portable Document Format Extension: pdf When a file of this type is encountered (.) Open it using the default application On the screen: File Type Details Description: Portable Document Format Extension(s): pdf When encountered: Open these files using the default application There is also an icon for PDF icon with the photograph- this suggests the Mac Previewer! But OTHER pdfs open fine. So what's going on?
Which pdf does it fail for?
I tried the first one again and it failed *immediately* (!) with this message: /Users/tds/aaa/entrybk-1.pdf could not be opened, because an unknown error occured. Sorry about that. Try saving to disk first and then openening the file. Why so sudden? Oh! I ALREADY HAVE a file by that name! ok, move it out of the way ... Hmm. That's weird. I moved the file to the trash. Got THE SAME MESSAGE. In my aaa directory files with odd names like 7fom6d71.pdf appear - but they go away if I click there and when I say OK on the error panel. Ok, empty the trash. Same error, pdf icon with name yvqlze3i.pdf appeared in aaa. I should mention - maybe this matters? That aaa is a POINTER on my desk top to ~/aaa. let's see if that matters. rename it and make an aaa on the desk top. Nope, same error as before. It's also failing *immediately* for the second pdf now. So the system is *different* somehow -maybe something in a cache is causing trouble?
Can you please try a current nightly build? The error-reporting there has been improved somewhat, so you may get a more useful error message.
I cleared the cache and tried the first one, entrybk.pdf it downloaded and failed at the end. So there is a collision with something in the cache. Now it is in immediate failure mode. Hmm. That's odd. In /Users/tds/Library/Mozilla/Profiles/tds/y2197nhk.slt/Cache there are LOTS OF FILES from January 2003! I moved all these files to /tmp ... still have the error. Oh. My trash is in /tmp/Cache... clear cache. download. long download and failure. new files are -rw-r--r-- 1 tds wheel 6144 13 Nov 14:20 _CACHE_001_ -rw-r--r-- 1 tds wheel 94032 13 Nov 14:20 35DA6632d01 tds% file * 35DA6632d01: PDF document, version 1.4 _CACHE_001_: data _CACHE_002_: data _CACHE_003_: data _CACHE_MAP_: pfm? BY GOLLY IT IS IN THE CACHE!!! Does it WORK?? YES!! I copied 35DA6632d01 to my aaa directory and although it had no .pdf it launched acrobat just fine. This proves that it has indeed downloaded. Download still fails. Ok, now remove JUST THAT FILE from the cache ... [bluebird:/private/tmp/Cache] tds% mv 35DA6632d01 /tmp Hmm. immediate download failure. Ok, remove 35DA6632d01 from aaa...still immediate failure. Ok. Delete _CACHE_001_ ... immediate failure. Ok, remove all files [bluebird:/private/tmp/Cache] tds% rm * immediate failure. Perhaps mozilla does not know that the files are gone. It is in the 'mind' of mozilla that the files are still there. Ok, clear cache the standard way. Oh oh! [bluebird:/private/tmp/Cache] tds% pwd pwd: : Permission denied It turns out that mozilla TOTALLY WIPES the Cache file, the entire directory is removed and then restored: [bluebird:/private/tmp/Cache] tds% ls _CACHE_001_ _CACHE_002_ _CACHE_003_ _CACHE_MAP_ Now of course, it does the long download and fails at the end. The new file is 35DA6632d01 as before (how curious) and is pdf and it launches just fine. SUMMARY: 1. The pdf is downloaded into /private/tmp/Cache. 2. The downloaded file is a perfectly fine pdf. 3. Clearing the cache wipes the file. next attempt does a full download, ending in failure. If the file is in the cache, the download does not occur, failure is immediate.
Ok, I'll do a nightly. This will take several hours to download.
I now have Mozilla 1.6a Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.6a) Gecko/20031029 going to http://www.sciserv.org/sts/documents/ and downloading the first pdf, I get this error message: /Users/tds/aaa/entrybk.pdf could not be opened, because the associated helper application does not exist. Change the association in your preferences. Ok, different error message ... Clear the cache ... Now it's downloading ... error message as above. Download again - immediate error message. the file in the cache launches acrobat just fine. Ok, look at the Preferences, Helper Applications, application/pdf switch from (.) Open it using the default application too ( ) Open it with: [Macintosh HD:Applications:Acrobat Reader 5.0] Failed as above. Do I really have a file /Applications/Acrobat Reader 5.0 ? [bluebird:~] tds% ls /Applications/Acrobat\ Reader\ 5.0 Contents/ Yes. Furthermore, clicking on that file launches acrobat 5.0. Ok, folks, I'm at the end of what I can do.
Reset the helper app because "Macintosh HD:Applications:Acrobat Reader 5.0" is not a valid path to the helper app anymore. The Mach-O builds of Mozilla do not work with the : delimited path names used by the CFM builds.
The problems with : delimited paths in the current builds are discussed in great detail in bug #166369 which Boris referred to several comments above btw.
Screw this. I'm just marking this duplicate, since telling people to read something clearly does not work. *** This bug has been marked as a duplicate of 166369 ***
Status: UNCONFIRMED → RESOLVED
Closed: 21 years ago
Resolution: --- → DUPLICATE
| Reset the helper app because "Macintosh HD:Applications:Acrobat | Reader 5.0" is not a valid path to the helper app anymore. The | Mach-O builds of Mozilla do not work with the : delimited path names | used by the CFM builds. Please say how to do this. I don't have time to dig into detailed code, just help point out errors.
You click the button to choose the app (It says "Choose" in my Linux build; no idea what it says on Mac), navigate to where your PDF viewer is installed, and select it.
Thanks Boris! I did that and ... it works perfectly! Immediate pop up in Acrobat 5 when it is in the cache (from before!) and 20 seconds to download and then pop up in acrobat if I have cleared the cache. on the mac the location is just the unix path: /Applications/Acrobat Reader 5.0 So this is a DOCUMENTATION BUG! That is, the message(s) were too obscure to know what to DO unless you have inside knowledge. All the mystery is resolved if you know what to do. I see that the current message actually MAKES SENSE. So why didn't I follow it? Because RTFM, right? No, I didn't trust it. So part of the problem is that - apparently - Mozilla changed the way it handles such names. Could it fix itself? Could it launch the preferences in the edit mode right away for a person?
Tom, please do read bug 166369 (as Steve and I have repeatedly requested). It covers the following aspects of your last comment: 1) The fact that the alert text was wrong, and why 2) The fact that we no longer work with ':'-delimited paths and why 3) What we need to change to work with them in this instance. It's just waiting for someone with a Mac to test on to produce a patch.
Product: Core → Core Graveyard
You need to log in before you can comment on or make changes to this bug.