In order to switch prefs to nsIFile, I need to have a way of persistently storing a file path on all three platforms, and later restoring the nsIFile from prefs. on Windows and Unix, I guess this is just the file path, but on Mac, we need to use the technique we used in nsIFileSpec: http://lxr.mozilla.org/seamonkey/source/xpcom/io/nsFileSpec.cpp#928 I have no idea who would do this for mac. I need this because GetPathPref() uses an nsIFileSpec, which is NOT i18n friendly - it doesn't support unicode paths, which means that you cannot store unicode paths in the prefs. I'll do the work for prefs (filing a bug now) when this is done.
cc'ing the platform junkies who did nsIFile for their respective platform. Can you guys read over this bug to see what I need? Thanks.
Moving all current open XPCOM and XPCOM Registry bugs to rayw since dp is on sabbatical. rayw is now default assignee for these components.
Assignee: dp → rayw
I researched this previously. I was told that existing path functions of nsIFile can be used for this purpose. If Mac needs to enhance these functions in a platform-specific way to address other concerns, then so be it. Is there a reason this cannot be solved simply on Mac without adding functions to the API?
Status: NEW → ASSIGNED
Changing to future until something more concrete is worked out between the clients that need this and the Mac implementors of nsIFile.
Target Milestone: --- → Future
note that I have have nominated this for nsbeta3 because this is necessary in order to have i18n-safe paths stored in preferences.
This has come up repeatedly. Apparently this was broken by the substitution of nsIFile for nsIFileSpec. I do not understand why this was not supplied in the base nsIFile implementation, or exactly what is required to put it there now, but I do not have either the hardware to try or the use case to know if I have solved the problem.
I posted to the newsgroup about this, but did not update the bug. the result of GetPath() can init an nsILocalFile using the InitWithPath function. If you want to make an explict streaming function in the base class, file a seperate bug. One problem is the Mac's implemention does not save off the current drive it is on, so if you have two volumes with idential names, your nsIFile may be invalid. This is a known problem on the mac and some of our subsystems are already broken: rdf, bookmarks, ect. I am going to mark this invalid.
Status: ASSIGNED → RESOLVED
Last Resolved: 18 years ago
Resolution: --- → INVALID
Wait a minute here. dougt: did you just blow off all the effort that we went into with nsFileSpec to work towards fixing the problem with multiple volumes with the same name? Are we throwing up our hands, and saying that we're not going to attempt to fix this? That's not good.
I would like to do that, yes! I think that we are spending way too much time adjusting for a os problem which we have no idea how many users it effects, and from what I understand the percentage may only be less than 1! People that have two volumes named the same, shouldn't. The mac implementation of nsILocalFile does not handle GetPath/InitWithPath correctly. It needs to return ALL needed information in order to construct itself. Right now, it just returns the MoreFile's Path! To fix the problem, we have to do is figure out a way to string-ify a path on the mac. I believe that a bug was filed for this and was assigned to steve dagley.
wait! this is not a viable solution - for one thing, users of NS6 beta1 and beta2 will have the persistent base64 string for various preferences, if we do not supply a way of converting that string into a valid nsIFile, we will never be able to drop nsIFileSpec because we will always need to rely on it for the conversion. So we MUST do the work anyway in order to drop nsIFileSpec
Status: RESOLVED → REOPENED
Resolution: INVALID → ---
alec, I am not sure I understand. nsIFile did not put any strings to preferences, so why should this interface/impl worry about converting things that are base64 encoded? Why is this not viable: call getPath() store it how ever you like. restore it how ever you need. call initWithPath() If it isn't, I can an persistant api.
no, it's not that nsIFile put stuff into preferences, it's because of nsIPref::SetFilePref(const char *prefName, nsIFileSpec* value) which takes an nsIFileSpec, saves it into prefs, using the persistent file string attribute of nsIFileSpec And there are lots of places that we use this: http://lxr.mozilla.org/seamonkey/search?string=getfilepref http://lxr.mozilla.org/seamonkey/search?string=setfilepref
I don't see any problem.
The problem is that people have existing prefs file which contain persistent file descriptors, which look like: user_pref("browser.download.dir", "AAAAAADIAAIAAQtPdGhlciBzdHVmZgAAAAAAAAAAAAAAAAAAAACz9P6IQkQAAAAAAAIORGVza3RvcCBG b2xkZXIAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAABTsLP25 1f//wAAAwAIAP//// 8AAAAAAAAAAAAAAAAAAAAAAAAAC090aGVyIHN0dWZmAAACABpPdGhlciBzdHVmZjpEZXNrdG9wIEZvbGR lcv//AAA="); (This is a Base-64 encoded alias handle). We need to be able to read these kinds of prefs.
So here's the deal with regard to the 2-volume problem on Mac: 1. We *cannot* store full paths persistently anywhere on Mac, either in the prefs file, in the Registry file, or the Components registry. If we do, then all hell will break loose if the user renames their hard disk (which people do quite often), or move the application to a different folder (which they can also do easily). Persistent file descriptors of the type output by nsFileSpec solve this issue by using Mac aliases, not full paths. Aliases are robust to renamed hard disks and moved folders. 2. We are willing to punt on the 2-volumes with the same name issue, so that full paths MAY be used AT RUNTIME ONLY (e.g. in file URLs). Full paths MUST NOT be stored persistently, for the reasons stated above.
why couldn't GetPath() just return this encoded handle?
Because there are times where we do want a normal file path to be returned from GetPath(). We need both, because they are applicable in different situations.
using GetPath to display something to the user, right? GetPath is not for use in NSPR, stdlib.
reassigning to conrad, and marking fixed. (Thanks conrad)
Assignee: rayw → conrad
Status: REOPENED → NEW
conrad checked this in last week.
Status: NEW → RESOLVED
Last Resolved: 18 years ago → 18 years ago
Resolution: --- → FIXED
Alec, please mark verified is all is well.
QA Contact: leger → alecf
yup, works great
Status: RESOLVED → VERIFIED
You need to log in before you can comment on or make changes to this bug.