Closed Bug 42099 Opened 24 years ago Closed 24 years ago

need persistent file string for nsIFile

Categories

(Core :: XPCOM, defect, P3)

Product:
Core
Component:
XPCOM
Platform:
x86
Linux
Type:
defect

Tracking

()

Status:
VERIFIED FIXED
Milestone:
Future

People

(Reporter: alecf, Assigned: conrad)

References

Details

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.
Blocks: 42102
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.
Keywords: nsbeta3
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
Closed: 24 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
Closed: 24 years ago → 24 years ago
Resolution: --- → FIXED
please verify
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.