197150 - Don't use '-' in unique file creation

Status: RESOLVED WONTFIX

(Core :: XPCOM, defect)

Description

[Matthew MacLeod]

User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.3) Gecko/20030310
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.3) Gecko/20030310

Around 1.3 RC1 I started getting the following behaviour:

When downloading an ofx file for my credit card (type 'text/ofx') my helper
application (Microsoft Money) was not launching. At first I thought it was just
that server, but then another banking site broke for me as well that was using
ofc files.

I've now narrowed it down to the following:
If the filename being downloaded exists in the 'temp' directory, the file
"download.ofx" will automatically be saved as "download-1.ofx" or
"download-2.ofx" as needed, but the application will not launch. Deleting the
files manually from the temp directory will allow it to work the next time, but
then the problem re-occurs.

This occurs on both 1.3 branch builds as well as current trunk builds. I believe
it was not present in 1.3b, although I could be mistaken.

Temp folder is in
"C:\Documents and Settings\[Logon Name]\Local Settings\Temp"

Reproducible: Always

Steps to Reproduce:
1. Go to a website that allows you to download a file that can be opened with a
helper application.
2. Click on it, attempt to open it.
3. Repeat a second time with the same file.

Actual Results:  
Helper application does not launch after the first time.

Expected Results:  
Helper application should launch with the file (or open the file if already
open). Or at the very least give an error.

Also see Bug 58667, which describes the problem of Mozilla not throwing an error
if an application does not launch.

Comment 1

[Matthias Versen [:Matti]]

-> File Handling

Comment 2

[Boris Zbarsky [:bzbarsky]]

Are you using the download manager or the progress dialog?  Does toggling that
option help?

Comment 3

[Matthew MacLeod]

I wasn't using the download manager. I just tried turning it on and got some
even weirder behaviour.

The download manager comes up with the "download.ofx" entry, but with no other
info listed. The download will not allow me to remove it, only to cancel/view
properties. Cancel has no effect at all. Poperties brings up a download window
with a frozen time. If I close it and re-open it will update to the time since
the download was initiated, but it does not animate/refresh. This persists
across closing and re-opening the download manager. If I close and restart
mozilla it will say "finished" and allow me to remove it.

Comment 4

[Boris Zbarsky [:bzbarsky]]

OK.  So this is a problem with both download manager and progress dialog, then?
 Thank you.

Comment 5

[Matthew MacLeod]

Yep...both progress and download manager methods show the bug.

I think I've got it narrowed. The MNYIMPRT.EXE doesn't like the hyphen character
in "download-1.ofx". Is it possible to ditch the "-"? "download1.ofx" works fine.

The rest of the weird behaviour appears to be just Bug 58667. I'll go vote for
it. :)

Comment 6

[Boris Zbarsky [:bzbarsky]]

We just use nsIFile::CreateUnique to create the filename; over to
networking:file (but I suspect there were reasons for having the '-' in there....)

Comment 7

[Christian :Biesinger (don't email me, ping me on IRC)]

Isn't nsIFile in XPCOM, rather than networking?

Comment 8

[Matthew MacLeod]

Also, whose responsibility is it to clear the files from the temp folder? I
think the reason I didn't see this bug before is that I only ever opened one
file with the same name per session, and it must have been deleted by Mozilla at
some point. This is no longer happening.

Looking in my temp folder here at work I have several post-1.3 upgrade opened
files in there, and none from pre-1.3. What I observed yesterday in my testing
with 1.2.1 is that files would persist until Mozilla was closed, at which point
they were deleted.

Comment 9

[Christian :Biesinger (don't email me, ping me on IRC)]

yeah, mozilla is supposed to delete the files when it shuts down; of course that
doesn't work if another application is keeping them open (code is in
nsExternalHelperAppService.cpp iirc)

Comment 10

[Boris Zbarsky [:bzbarsky]]

Yeah, xpcom/networking; it's all dougt.  ;)

Comment 11

[Gervase Markham [:gerv]]

This is an automated message, with ID "auto-resolve01".

This bug has had no comments for a long time. Statistically, we have found that
bug reports that have not been confirmed by a second user after three months are
highly unlikely to be the source of a fix to the code.

While your input is very important to us, our resources are limited and so we
are asking for your help in focussing our efforts. If you can still reproduce
this problem in the latest version of the product (see below for how to obtain a
copy) or, for feature requests, if it's not present in the latest version and
you still believe we should implement it, please visit the URL of this bug
(given at the top of this mail) and add a comment to that effect, giving more
reproduction information if you have it.

If it is not a problem any longer, you need take no action. If this bug is not
changed in any way in the next two weeks, it will be automatically resolved.
Thank you for your help in this matter.

The latest beta releases can be obtained from:
Firefox:     http://www.mozilla.org/projects/firefox/
Thunderbird: http://www.mozilla.org/products/thunderbird/releases/1.5beta1.html
Seamonkey:   http://www.mozilla.org/projects/seamonkey/

Comment 12

[Christian :Biesinger (don't email me, ping me on IRC)]

confirming

Comment 13

[:Gavin Sharp [email: [e-mail]]]

MNYIMPRT.exe seems to be some old Microsoft Money application. Is it really worth changing CreateUnique's behavior just because one application doesn't like dashes in filenames? Or am I misunderstanding this bug?

Comment 14

[Boris Zbarsky [:bzbarsky]]

You understand correctly, but are people relying on the filenames CreateUnique produces or something?  If not, this should be an ok change, and if it makes more things work...

Comment 15

[:Gavin Sharp [email: [e-mail]]]

I think there should be very good reason to change something like CreateUnique, whose behavior in this respect hasn't changed since it was created in 2000. I'm not sure that one old bug report about one old app is a very good reason. Is there any evidence that this is problematic for programs other than MNYIMPRT.EXE?

Comment 16

[Matthew MacLeod]

Wow, I had forgotten about this one.  I've converted from Money to Gnucash, so it's not affecting me personally any more.  I can live without it being fixed.

As I mentioned earlier in this bug, Bug 58667 is the real problem.  If launching external apps doesn't work perfectly in every single case with every wacky old app (which is impossible) it should throw some sort of error so the user knows what's going on and can recover.

Comment 17

[Boris Zbarsky [:bzbarsky]]

OK, I think we should wontfix this, then.