need persistent file string for nsIFile




18 years ago
18 years ago


(Reporter: Alec Flett, Assigned: Conrad Carlen)



Firefox Tracking Flags

(Not tracked)




18 years ago
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

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:

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.


18 years ago
Blocks: 42102

Comment 1

18 years ago
cc'ing the platform junkies who did nsIFile for their respective platform.
Can you guys read over this bug to see what I need?
Keywords: nsbeta3

Comment 2

18 years ago
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

Comment 3

18 years ago
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?

Comment 4

18 years ago
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

Comment 5

18 years ago
note that I have have nominated this for nsbeta3 because this is necessary in 
order to have i18n-safe paths stored in preferences.

Comment 6

18 years ago
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.

Comment 7

18 years ago
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.
Last Resolved: 18 years ago
Resolution: --- → INVALID

Comment 8

18 years ago
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.

Comment 9

18 years ago
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.


Comment 10

18 years ago
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
Resolution: INVALID → ---

Comment 11

18 years ago
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.


Comment 12

18 years ago
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:

Comment 13

18 years ago
I don't see any problem.  

Comment 14

18 years ago
The problem is that people have existing prefs file which contain persistent file 
descriptors, which look like:


(This is a Base-64 encoded alias handle).

We need to be able to read these kinds of prefs.

Comment 15

18 years ago
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.

Comment 16

18 years ago
why couldn't GetPath() just return this encoded handle?

Comment 17

18 years ago
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.

Comment 18

18 years ago
using GetPath to display something to the user, right?

GetPath is not for use in NSPR, stdlib.

Comment 19

18 years ago
reassigning to conrad, and marking fixed. (Thanks conrad)
Assignee: rayw → conrad

Comment 20

18 years ago
conrad checked this in last week.
Last Resolved: 18 years ago18 years ago
Resolution: --- → FIXED
please verify

Comment 22

18 years ago
Alec, please mark verified is all is well.
QA Contact: leger → alecf

Comment 23

18 years ago
yup, works great
You need to log in before you can comment on or make changes to this bug.