531234 - Zone.Identifier files if the download directory is a (Windows-) network share

Status: RESOLVED WONTFIX

(SeaMonkey :: Download & File Handling, defect)

Description

[Micha]

User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.9.1.4) Gecko/20091017 SeaMonkey/2.0
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.9.1.4) Gecko/20091017 SeaMonkey/2.0

If you download a file and save it to a "network drive" - a Windows network share provided by Apache in my case - SeaMonkey places a Zone.Identifier File too. Normally, on local drives with NTFS attributes, this is done a a second file stream to the downloaded file. The additional file has the naming downloaded_filename:Zone.Identifier. The file is generated independently of the file type. 

Additionally SeaMonkey ignores local policy settings at all as reported for Firefox 3.5 in Bug #499448. Even the older described workaround do not work.

Reproducible: Always

Steps to Reproduce:
1. Start a download
2. Select a network share as destination
3. After the download has finished, look into the download directory


Expected Results:  
Just the downloaded file, but no additional Zone.Identifier File, if the filesystem does not support multiple filestreams.

Comment 1

[therube]

Just a thought, but if you add (newly create) the Preference item (type Boolean):

> browser.download.manager.alertOnEXEOpen

does that alleviate the situation?


(Alternative Data Streams | ADS)

"Prevent from tagging ADS Zone.Identifier$DATA"
http://forums.mozillazine.org/viewtopic.php?f=40&t=2018879&p=10056905#p10056905

Comment 2

[therube]

Oops.  Add to the above ...

> but if you add (newly create) the Preference item (type
Boolean)

... setting it to /false/.


I cannot seem to forcibly generate this Zone.Identifier File on a straight Windows shared networked drive, so perhaps you Apache setup has a bearing on this?

Comment 3

[therube]

Saving a file to a Buffalo NAS (using the XFS file system) I also cannot generate any Zone.Identifier files.

http://en.wikipedia.org/wiki/XFS

Comment 4

[Philip Chee]

> Saving a file to a Buffalo NAS (using the XFS file system) I also cannot
> generate any Zone.Identifier files.

> http://en.wikipedia.org/wiki/XFS

"XFS provides multiple data streams for files through its implementation of extended attributes"

This bug is about network shares that *don't* support alternate data streams.

Comment 5

[Philip Chee]

bug 499448 comment 3:

> There is a workaround for this issue that involves editing your preferences in
> about:config.
> 
> First, change the value for browser.download.manager.scanWhenDone to false.
> Next, add a new boolean preference named
> browser.download.manager.skipWinSecurityPolicyChecks and set its value to true.
> Finally, create another boolean preference named
> browser.download.manager.alertOnEXEOpen and set it to false.
> 
> These three need to be in effect before the Zone.Identifier information is no
> longer saved with the file.

I implemented browser.download.manager.scanWhenDone in Bug 569204 so this should be fixed in SeaMonkey 2.1aSomething.

Anyone want to recheck with:
1. SeaMonkey 2.1b1.
2. On a network share that does not support alternate data streams.
3. With the above preferences set.

Comment 6

[Philip Chee]

Should have been fixed in Bug 504804 - prefs cleanup and smarter integration with win policy settings. Can anyone verify?

Comment 7

[Thomas Wolff]

I confirm that browser.download.manager.scanWhenDone=false suppressed the extra file (SeaMonkey 2.8).
It's not a solution though, because I don't want to have to skip some essential scanning just to get rid of this superfluous file.

Comment 8

[Masatoshi Kimura [:emk]]

Isn't it reproducible using IE?

Comment 9

[Thomas Wolff]

Yes. Which makes it not quite a bug of SeaMonkey or a Mozilla issue in general.
(Probably a bug of the scanner software adding some nonsense information...)
Let's close it here.

Comment 10

[Philip Chee]

> Let's close it here.
Fine by me. Closing as CANTFIX.