Support pathnames in nsLocalFileOSX::SetPersistentDescriptor

RESOLVED FIXED

Status

Core Graveyard
File Handling
RESOLVED FIXED
12 years ago
2 years ago

People

(Reporter: Mark Mentovai, Assigned: Mark Mentovai)

Tracking

({fixed1.8.1})

Trunk
PowerPC
Mac OS X
fixed1.8.1

Firefox Tracking Flags

(Not tracked)

Details

Attachments

(1 attachment)

(Assignee)

Description

12 years ago
Right now, the nsILocalFile implementation on Mac OS X uses opaque alias records in base64 encoding for persistent descriptors.  This is the source of all of that non-editable garbage in the prefs for things like browser.download.defaultFolder, where other platforms use pathnames.

I'd like to extend SetPersistentDescriptor to accept pathnames on Mac OS X as well.  Because the base64 encoding used for alias records doesn't use the characters '/' or '~', I propose that any string passed to SetPersistentDescriptor beginning with either of those characters be treated as a pathname.

I'm not proposing that we modify GetPersistentDescriptor to return pathnames at this time: that method should continue to return base64-encoded alias records, so prefs set through an application's UI will continue to be set in an unreadable base64 form.  There are two reasons for this: to retain profile backwards compatibility, and to retain the functionality of alias records for the time being.  Alias records are what allow the system to follow moved and renamed files, and we should consider this carefully before discontinuing their use.  More background on alias records is available at http://developer.apple.com/documentation/Carbon/Reference/Alias_Manager/ .

A good reason to do this is a by-product of bug 311292 may be a hidden pref to specify a directory, and users will have a much easier time modifying this pref if they should choose to do so if they are able to set a native pathname.

I would like to get this change in for 1.8.1, because it will make it easier to change GetPersistentDescriptor to return pathnames the future, if we elect to.  If we make the proposed SetPersistentDescriptor change for 1.8.1, then Firefox 2 will not experience profile compatibility problems should Firefox 3 (or some higher number) begin putting pathnames into the prefs.

This bug report is long.  The actual implementation will be about 3 lines long.
(Assignee)

Comment 1

12 years ago
Created attachment 230056 [details] [diff] [review]
Patch v1

Like I said, three lines.
Attachment #230056 - Flags: review?(joshmoz)

Updated

12 years ago
Attachment #230056 - Flags: review?(joshmoz) → review+
(Assignee)

Updated

12 years ago
Attachment #230056 - Flags: superreview?(darin)

Updated

12 years ago
Attachment #230056 - Flags: superreview?(darin) → superreview+
(Assignee)

Comment 2

12 years ago
Comment on attachment 230056 [details] [diff] [review]
Patch v1

Rationale for 1.8.1 in comment 0.
Attachment #230056 - Flags: approval1.8.1?
(Assignee)

Updated

12 years ago
Status: NEW → RESOLVED
Last Resolved: 12 years ago
Resolution: --- → FIXED
Comment on attachment 230056 [details] [diff] [review]
Patch v1

a=drivers. Please go ahead and land this on the branch.
Attachment #230056 - Flags: approval1.8.1? → approval1.8.1+
(Assignee)

Comment 4

12 years ago
Checked in on MOZILLA_1_8_BRANCH before 1.8.1b2.
Keywords: fixed1.8.1
Product: Core → Core Graveyard
You need to log in before you can comment on or make changes to this bug.