148915 - Filenames Migrated Instead of Foldernames

Status: RESOLVED INCOMPLETE

(Core Graveyard :: Profile: Migration, defect)

Description

[Felix Miata]

2002060216 OS/2 (release branch?)

To reproduce:
1-Make one or more mailnews folder names in Netscape 4 nine or more characters
in length. Netscape gives you the folder names you like, but on HPFS disk the
names take the form: 123456AA.
2-Migrate the profile

Actual behavior:
1-The folder names within Mozilla use the actual filenames used by Netscape and
Mozilla in the form 123456AA

Expected behavior:
1-The folder names within Mozilla use the folder names used by Netscape
2-The filenames for Mozilla match the folder names, such as 1234567890

Comment 1

[Mike Kaply [:mkaply]]

Is this really new with this build?

Comment 2

[Felix Miata]

Definitely not new. It goes back way farther than I can remember, maybe before I
tried Mozilla the very first time, well over a year ago.

Comment 3

[Mike Kaply [:mkaply]]

This can't be fixed.

The SNM files which contain the long name are a proprietary format from 
Neologic.

This format can only be read with an official Netscape release that has licensed 
the code.

Because we chose to make our files 8.3 on 4.x, this is the way it has to be.

I'll add info about this to the readme.

Comment 4

[Felix Miata]

I understand need for a license to write a proprietary format. Why would a
license be required to read it? Aren't other proprietary formats like pdf
readable with GPL freeware?

Comment 5

[Mike Kaply [:mkaply]]

Someone else could write something to read it, but no IBM or Netscape 
employee could since we are licensed to the companies code and have 
seen it.

Comment 6

[Felix Miata]

If that is the case, then WONTFIX doesn't seem to be appropriate. Someone
outside IBM and Netscape at least theoretically *could* provide a fix.

Comment 7

[K'Trina Medina]

Any takers? 

Comment 8

[K'Trina Medina]

Adding keyword helpwanted in case anyone outside IBM or Netscape wants to
provide a fix before we close this one out.

Comment 9

[K'Trina Medina]

Verified wontfix. Sorry mrmazda. There doesn't seem to be any takers. 

Comment 10

[Felix Miata]

What's the bloody rush to wontfix? Today is not the end of the world. People
busy today may not be so busy next week or whenever. This should be marked
future, helpwanted, etc, not wontfix just because the port owner can't do it.
Once you wonffix, nobody even knows the problem exists. Then next week or next
month or next year somebody else files the exact same bug anew, because Bugzilla
omits by default "resolved" bugs, even though not really resolved. Lame, really
lame.

Comment 11

[K'Trina Medina]

I didn't mean to offend you. My apologies. Reopening and marking this future.

Comment 12

[(not reading, please use [e-mail] instead)]

mass re-assign.

Comment 13

[Mike Kaply [:mkaply]]

Not OS/2 specific

See:

http://bugzilla.mozilla.org/show_bug.cgi?id=87380

Comment 14

[(not reading, please use [e-mail] instead)]

sorry for the spam.  making bugzilla reflect reality as I'm not working on these bugs.  filter on FOOBARCHEESE to remove these in bulk.

Comment 15

[Serge Gautherie (:sgautherie)]

Filter on "Nobody_NScomTLD_20080620"

Comment 16

[Benjamin Smedberg]

This bug is filed in a bugzilla component related to pre-Firefox code which no longer exists. I believe it is no longer relevant and I am therefore closing it INCOMPLETE.

If you believe that this bug is still valid and needs to be fixed, please reopen it and move it to the Toolkit:Startup and Profile System product/component.