Under certain download conditions I get the following error: status is failure *access("/tmp/pmz496fs.rm",1) = -1 (xok fix) Of course there is no directory tmp in VMS. I suppose it should be sys$scratch, or should a logical tmp be defined in mozilla.com? (define tmp sys$scratch)

What exactly is the problem? Your report shows two debug messages which appear on the "console", but no bug description. Are you just reporting those two messages? If you are experiencing a real download problem, please provide details, along with which version of Mozilla you are using.

Sorry for the confusion, here are some details. I clicked on a Realplayer file (.rm). Since there is no Realplayer plugin for VMS, Mozilla asked me if I wanted to save the file. and I did of course. I have the impression that the download will start before I'm asked where to save the file. In such a case the download appears to go to a scratch file first, is again my impression. It seems Mozilla will try to open the scratch file in the directory tmp, but that directory does not exist. After I agreed to save the file I got several unclear warning messages. Again, this is speculation. But is it possible that mozilla assumes there is a scratch directory tmp for more then just these kind of operations? And I'm a bit surprised the version information etc. did not come through. When I entered the bug, bugzilla told me exactly which version Mozilla I am using, OS, computer type etc. , and I assumed this information would be in the bug report. but it is Mozilla build 2002020910 (0.9.9.), and VMS 7.3 with all patches.

Don't worry, /tmp does exist, on OpenVMS its your SYS$SCRATCH directory. So under normal conditions the file can be saved OK. So I guess this means there must be something abnormal on your system. Things which come to mind immediately are: 1. Do you have TMP defined as a logical? 2. What is the protection on your SYS$SCRATCH directory? 3. Do you have a file named SYS$SCRATCH:.; I have seen 3 cause problems before. If you do have such a file, delete it!

Dirk, can you reply to comment #3. Thanks, Colin.

Hi Colin, I haven't defined TMP myself, but it had been defined as SYS$SCRATCH in my job table. And SYS$SCRATCH has been defined as my user directory (standard). Dir sys$scratch:. will give readme. in my user directory as result. Regards, Dirk

Can you try deassigning TMP before running Mozilla and then see if the download works?

Dirk, I've done some more testing and I think what you are seeing is the effect of bug 115819. When you see this problem, do you get a dialog box with missing text? Please view attachment 66276 [details] and let me know if you see this. I believe there is a timing bug in the download code and when this bug hits you (a) get the broken dialog box, (b) see "/tmp" in the debug access message instead of whatever your login directory really is, and (c) end up with the downloaded file left in /tmp with its temporary name. Does this describe exactly what you are seeing?

Hi Colin, Yes, attachment 66276 [details] is exactly what I am seeing. This happens from my local web server (on the same machine) and from slow remote web servers. Seems to be a difficult problem judging from the text with bug 115819 ....

*** This bug has been marked as a duplicate of 115819 ***

marking verified as a duplicate. if you decide to reopen this bug, please clarify why. search string for bugspam removal: SalviaGuaranitica