firefox does not save an attachments starting with dot

[Jan Groenewald]

When I download & save a file and I change the name to start with a dot,
it 0) prompts me to replace the existing dot file, if it exists, 1) removes the
existing dot file, and 2) silently removes the dot and saves it with the name.

Example, someone mailed me a .bash_completion to replace an existing one,
and it removed the existing but saved /home/me/bash_completion.

I consider it a bug to not save dot-files if I ask for it, or to not give a proper
error message if it refuses. If upstream disagrees, it is at least a bug to
remove the existing dot-file if it refuses to save over it.

[Bill+mozilla-bugzilla (bill+mozilla-bugzilla)]

HFS doesn't permit a file to have a '.' character in the initial position.

This should be removed for the user attempting to save a file. I happen to know about OS9 drivers so it only took me 30 seconds to figure out why the 'Save' button wasn't lit up, but it's not terribly obvious for the typical user. It would be good to filter this (and any other illegal characters) for the user.

[Bill+mozilla-bugzilla (bill+mozilla-bugzilla)]

Oops - spazzed...

tested on Firefox 2.0b1

Steps to Reproduce:
1: Load URL with . as initial character of last part (see URL field)
2: Attempt to Save Page As...

Actual Results:
Save button not lit up. Removing the . allows the Save button to light.

Expected Results:
Filter the illegal character for the user

[Mark Mentovai (mark-moxienet)]

Which OS? On 10.4, the standard dialog doesn't prevent you from saving a file whose name begins with a dot. You'll be warned, complete with poor wording and punctuation, after clicking Save:

| Names that begin with a dot “.” are reserved for the
| system. If you decide to go ahead and use a name
| which begins with a dot the file will be hidden.
| (Cancel) (Use “.”)

Cancel is the default (responding to Return and Escape), Use is focused (responding to Space).

It's probably still a good idea to not suggest names beginning with a dot anyway.

[Mark Mentovai (mark-moxienet)]

Stripping leading dots from the suggested filename should probably be cross-platform.

[Jruderman (jruderman)]

See also bug 290720.

[Bill+mozilla-bugzilla (bill+mozilla-bugzilla)]

(In reply to comment #2)
> Which OS?

10.3

So on 10.3 they won't work, on 10.4 and other unixes they'll be hidden - anybody know what happens on Windows? I don't mind if somebody makes this cross-platform; I just don't have a strong feeling one way or the other.

[Bill+mozilla-bugzilla (bill+mozilla-bugzilla)]

(In reply to comment #4)
> See also bug 290720.

Security bug? (access denied)

[Jruderman (jruderman)]

Yes, bug 290720 is a security bug.

[Gavin Sharp (gavin-sharp)]

Created attachment 261821
remove leading dot before saving (landed on trunk and branches, bug 304345)

Got r=mano over IRC. I'll fix the other part of this, which is to remove leading dots in the prompt, separately.

[Gavin Sharp (gavin-sharp)]

Comment on attachment 261821
remove leading dot before saving (landed on trunk and branches, bug 304345)

I think it would be good to get this fix on the branches, as well.

[Dveditz (dveditz)]

Comment on attachment 261821
remove leading dot before saving (landed on trunk and branches, bug 304345)

approved for 1.8.0.12 and 1.8.1.4, a=dveditz

[Neil-httl (neil-httl)]

I know IanN likes our filename generation code ;-)

[Gavin Sharp (gavin-sharp)]

Landed that patch on the branches.

[Dveditz (dveditz)]

Adding the fixed1.8.0.12 and fixed1.8.1.4 to reflect the fact that the patches in this bug landed, but it doesn't actually fix the described bug so leaving open on trunk for a better fix.

[Sgautherie-bz (sgautherie-bz)]

Created attachment 290983
(Bv1-SM) Port to SeaMonkey <contentAreaUtils.js> [Checkin: Comment 16]

[Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.9b2pre) Gecko/2007120103 SeaMonkey/2.0a1pre] (nightly) (W2Ksp4)

Successfully tested with <http://www.leginfo.ca.gov/.const/.article_13A> + Ctrl+S,
by temporarily commenting out |if (!aDefaultExtension) ...|.

[Sgautherie-bz (sgautherie-bz)]

Created attachment 290989
(Cv1-SM-18) Port to SeaMonkey branch [Check-in: Comment 24]

Same as Bv1-SM, but /xpfe instead of /suite.

"approval1.8.1.12=?":
Actually, I'm looking for SeaMonkey Council approval ... but there's no flag for that :-/

[Reed Loden (reed)]

Bv1-SM:

Checking in suite/common/contentAreaUtils.js;
/cvsroot/mozilla/suite/common/contentAreaUtils.js,v <-- contentAreaUtils.js
new revision: 1.151; previous revision: 1.150
done

[Sgautherie-bz (sgautherie-bz)]

(In reply to comment #13)
> [...], but it doesn't actually fix the described bug so leaving
> open on trunk for a better fix.

What are the remaining bug and wanted behavior ?
Would moving |if (!aDefaultExtension) ...| after the regexs fix this bug ?
(The first regex was added there in bug 290381...)

[Kairo-kairo (kairo-kairo)]

Does that mean I can't just go straight in and download a .htaccess file provided on some site to some collection of web pages I (or a user) am creating for my personal homepage? Actually, I'd consider _that_ a bug.

[Sgautherie-bz (sgautherie-bz)]

(In reply to comment #18)
> Does that mean I can't just go straight in and download a .htaccess file

It depends on what your "that" refers to:
*The current patch ? It seems not to modify such filenames ("without extension"): see comment 14.
*The whole bug ? I don't know yet: see comment 17.

[Jruderman (jruderman)]

Robert, I imagine you'll have to add the dot yourself. I don't think that's too much to ask.

[Kairo-kairo (kairo-kairo)]

It's broken behavior, and there are all kinds of sample dot-files with settings for Linux/Unis programs around that people now have to fix up and novices will not realize that, esp. as the documentation on the websites for what to do with them won't mention that as they are offering the file with the dot after all.

IMHO this is a bad regression in behavior, and unless there is a huge security problem with saving dotfiles, I don't think it's a solution to anything but some obscure, probably old filesystem for a single platform, like mentioned in comment 0 - an initial dot is a standard thing to have on unix-based OSes, like OS X or Linux.

[Gavin Sharp (gavin-sharp)]

(In reply to comment #21)
> IMHO this is a bad regression in behavior, and unless there is a huge security
> problem with saving dotfiles

Perhaps not a "huge security problem", but bug 304345 was the original motivation for fixing this bug.

[Kairo-kairo (kairo-kairo)]

Comment on attachment 290989
(Cv1-SM-18) Port to SeaMonkey branch [Check-in: Comment 24]

OK, the argument derived from the other bug that I could be convinced with is actually that those downloaded files end up hidden, which makes a bad user experience if the user doesn't know what he's doing ;-)
approval-seamonkey1.1.8=me due to that, please add the fixed-seamonkey1.1.8 keyword when it's landed. Probably we even should relnote that.

[Reed Loden (reed)]

Cv1-SM-18:

Checking in xpfe/communicator/resources/content/contentAreaUtils.js;
/cvsroot/mozilla/xpfe/communicator/resources/content/contentAreaUtils.js,v <-- contentAreaUtils.js
new revision: 1.134.2.6; previous revision: 1.134.2.5
done

[Gavin Sharp (gavin-sharp)]

If I recall correctly, I left this open because the original request was to strip the leading dot before prompting, instead of before saving, but we only implemented the latter. If what we're doing now is properly removing the dot in the suggested filename for the filepicker then this can be resolved.

[Jo-hermans (jo-hermans)]

*** Bug 512676 has been marked as a duplicate of this bug. ***

[Timur Tabi (timur-tabi)]

What is the status of this bug? I just tried several times to save a file called ".pwclientrc", only to wonder why I couldn't find it. After a few minutes, I noticed that the file was saved as "pwclientrc". The problem is that the save-as dialog box specifically said ".pwclientrc" (with the leading dot).

The current behavior is, IMHO, seriously broken. If we want to solve the problem in bug 290720 (which I can't view, so I don't know what the problem actually is), we should at least change the filename in the dialog box. If I change it back to add the leading dot, then Seamonkey should save it with the dot.

[Roquentin (antonio-roquentin-deactivatedaccount)]

Thank you for reporting this bug. Could you specify which version of firefox and ubuntu are you using? I cannot reproduce this bug in ubuntu 12.04 with firefox 14.0. If I try to save a text file from firefox and rename it so as to start with a dot, the file is correctly saved with the expected initial dot. When I try again and overwrite the file, I see no removal of the initial dot.

[Jan Groenewald (jan-aims)]

Hi

On 21 July 2012 13:32, Antonio Roquentin <email address hidden> wrote:

> Thank you for reporting this bug. Could you specify which version of
> firefox and ubuntu are you using? I cannot reproduce this bug in ubuntu
> 12.04 with firefox 14.0. If I try to save a text file from firefox and
> rename it so as to start with a dot, the file is correctly saved with
> the expected initial dot. When I try again and overwrite the file, I see
> no removal of the initial dot.
>

It is Ubuntu 12.04, 64bit, all packages up to date,
 ii firefox 14.0.1+build1- Safe and easy web browser from Mozilla

When I click on a gmail attachment, application.doc, choose "download",
and change the filename to save to ".application.doc" it ignores the dot
and saves "application.doc" instead.

Regards,
Jan

[Roquentin (antonio-roquentin-deactivatedaccount)]

It seems like you are experiencing this bug

https://bugzilla.mozilla.org/show_bug.cgi?id=346994

I can now confirm that "Save link as" does not allow saving such files. However, "Save page as" allows me to rename the file so that it starts with a dot.

[Jan Groenewald (jan-aims)]

Perhaps upstream will not want to change this behaviour.
That is fine.

Then firefox should at least tell the user what it is doing!

And it should certainly not remove existing files if it is not going
to overwrite them.

When I saved an email attachment .bash_completion,
1) it removed my existing .bash_completion (yes, it prompted me to replace
and I accepted)
2) it saved bash_completion (without the dot)
3) it clearly misinformed me about above.

[Firesock-serwalek (firesock-serwalek)]

Created attachment 8428934
leading_period.patch

nsHelperAppDlg.js checks with the user to remove a leading period file, removes it and then saves the file without the period.

Patch to check here and only remove the file if the final name matches.

What's the current policy on this as well? According to this bug, all leading periods should be removed when saving, but none of the paths in toolkit/content/contentAreaUtills.js seem to do so? So it can save leading period files that way.

[Gavin Sharp (gavin-sharp)]

Comment on attachment 8428934
leading_period.patch

Thanks for the patch Awad - any chance you can file a separate bug for this? It's generally a bad idea to track multiple separate patches in the same bug, particularly one as old as this one. Please needinfo me on the new bug and I can help get this reviewed/landed.

[Firesock-serwalek (firesock-serwalek)]

Comment on attachment 8428934
leading_period.patch

Yep, no problem, wasn't quite sure what to do with this. Added a new bug 1022061.