libpref has a couple of uses of nsIFileSpec instead of using nsILocalFile

This patch removes the last uses of nsFileSpec from libpref and changes the callers of those functions. Unfortunately, it also involves modifying nsIPrefBranch.idl which was frozen with support for nsIFileSpec.

Comment on attachment 129040 [details] [diff] [review] v1.0 >Index: mailnews/base/src/nsMessengerMigrator.cpp >=================================================================== >RCS file: /mozroot/mozilla/mailnews/base/src/nsMessengerMigrator.cpp,v >retrieving revision 1.101 >diff -u -r1.101 nsMessengerMigrator.cpp >--- mailnews/base/src/nsMessengerMigrator.cpp 9 Apr 2003 00:47:38 -0000 1.101 >+++ mailnews/base/src/nsMessengerMigrator.cpp 1 Aug 2003 21:17:04 -0000 >@@ -233,17 +233,24 @@ > { \ > nsresult macro_rv; \ > nsCOMPtr <nsIFileSpec>macro_spec; \ >- macro_rv = m_prefs->GetFilePref(PREFNAME, getter_AddRefs(macro_spec)); \ >+ nsCOMPtr <nsILocalFile>macro_file; \ >+ nsFileSpec macro_filespec; \ >+ macro_rv = macro_spec->GetFileSpec(&macro_filespec); \ > if (NS_SUCCEEDED(macro_rv)) { \ >- char *macro_oldStr = nsnull; \ >- macro_rv = macro_spec->GetUnixStyleFilePath(&macro_oldStr); \ >- if (NS_SUCCEEDED(macro_rv) && macro_oldStr && (PL_strlen(macro_oldStr))) { \ >+ macro_rv = NS_FileSpecToIFile(&macro_filespec, getter_AddRefs(macro_file)); \ >+ if (NS_SUCCEEDED(macro_rv)) { \ Why is an uninitialized nsIFileSpec being converted to an nsIFile before passing it to GetFileXPref()? GetFileXPref() will initialize the out file param, blowing away the value you're setting up above. >+ macro_rv = m_prefs->GetFileXPref(PREFNAME, getter_AddRefs(macro_file)); \ >+ if (NS_SUCCEEDED(macro_rv)) { \ >+ nsCAutoString macro_oldStr; \ >+ macro_rv = macro_file->GetNativePath(macro_oldStr); \

Comment on attachment 129040 [details] [diff] [review] v1.0 Overzealous copy-n-pasting coupled with lack of understanding of the code involved? :) I didn't realize that GetFileXPref would initialize the nsIFile param. I thought it needed to be passed a valid nsIFile.

Comment on attachment 129040 [details] [diff] [review] v1.0 Index: modules/libpref/src/nsPref.cpp -#include "nsIFileSpec.h" +#include "nsDependentString.h" Any idea what causes us to need nsDependentString.h there?

The only hits I get when searching for "nsFileSpec" in files matching "pref" are in /profile/pref-migrator: http://mxr.mozilla.org/seamonkey/search?string=nsFileSpec&find=pref&findi=&filter=&tree=seamonkey Bug 214793 is about those, so marking this as WFM.

Reopening and morphing bug to removing nsIFileSpec. There are 19 matching lines in libpref for those: http://mxr.mozilla.org/seamonkey/search?string=nsIFileSpec&find=libpref&findi=&filter=&tree=seamonkey

Down to "Found 9 matching lines in 3 files". This is the last actual user of this interface...

http://mxr.mozilla.org/comm-central/search?string=nsIFileSpec&find=libpref&findi=&hitlimit=&tree=comm-central There are no actual consumers of this interface and both GetFilePref() and SetFilePref() both return NS_ERROR_NOT_IMPLEMENTED; Serge, time to remove two of these files? nsIPrefBranch.idl is frozen but does removing two comment lines change the IDL?

Judging by the bug reports, it looks like now both nsIFileSpec (and all of xpcom/obsolete) and nsIPref have been removed from the tree. And this search (and the comm-central one in comment #8) return no results: http://mxr.mozilla.org/mozilla-central/search?string=nsIFileSpec&find=libpref&findi=&filter=&hitlimit=&tree=mozilla-central So is there anything left to do in this bug?

We can close this bug. nsIFileSpec and nsIPref were removed from tree. But we should remove comment of http://mxr.mozilla.org/mozilla-central/source/widget/src/xpwidgets/nsTransferable.cpp?mark=90-91#90

Serge made a bug for that (and some other comments), bug 530352.