Talk:Profile folder

From MozillaZine Knowledge Base
Revision as of 16:41, 18 May 2007 by Np (talk | contribs)
Jump to navigationJump to search

The content of this article was migrated manually from Profile Folder. For previous article Talk and Talk History, see Talk:Profile Folder and [1], respectively. For previous article History, see [2]. --wintogreen 16:19, 26 December 2005 (UTC)


"Profile files" Category

What do you think of making a category that would contain an article for each file in the profile? We could describe what the file does, the consequences of deleting it, etc. Another thing we could do us have Category: Profile files (Firefox) and Category: Profile files (Thunderbird), etc. so each application's users can have a list that applies to them without seeing the cruft.--Np 18:25, 29 January 2006 (UTC)

I am strongly in favour of this idea. There is plenty to be said about each of the files in the Profile folder. --Mozcerize 11:04, 30 January 2006 (UTC)
Great idea. Another tidbit that would be useful is whether the file can moved directly from one profile to another (without having to worry about absolute paths, etc.). --wintogreen 13:22, 30 January 2006 (UTC)
I agree, and I would suggest that the new category be a subcategory under Profiles and that it include both files and folders (Cache, bookmarkbackups, searchplugins, etc). I was noticing myself that certain files such as localstore.rdf, mimeTypes.rdf and downloads.rdf get corrupted and deleting them is often suggested as a fix. I've posted some links to forum topics for those three files on the Issues with Firefox page but a kb article link would be much better. I would just suggest that any guidelines for a new "Profile Contents (Firefox)" subcategory (or whatever) be linked from a location where editors can find it as I mentioned on the Knowledge_Base_changes page regarding the Category_talk:Preferences guidelines. Alice Wyman 14:12, 30 January 2006 (UTC)
How do you propose avoiding duplication between a issues article and the corresponding files article? For example, suppose I wrote a thunderbird issue article on how to fix problems with opening an attachment with the desired utility by deleting mimetypes.rdf. The user has a much greater chance of finding/reading the issues article and its also likely to be written for a less technical user. The solution may occasionally involve modifying more than one file in the profile. For example, http://kb.mozillazine.org/Phantom_folders has the user delete several files in the profile.
Looking at the articles in http://kb.mozillazine.org/Category:Preferences its clear a lot of effort was spent writing them and they have usefull information, but they're not focused on solving problems. IMHO they're really reference articles. I would expect the exact same thing to occur. If it does, then we need some way (a sentence in the rules?) to discourage an author of the file article from lobotomizing the issues article and adding a link to thier article to "avoid duplication". This problem may never occur, but I'd prefer we find some way to prevent it rather than deal with it later. Tanstaafl 23:27, 31 January 2006 (UTC)
Indeed, these would be reference articles. I don't really see much duplication. The issue article would describe a problem and say "...to fix it, delete downloads.rdf in your profile folder". The reference article would say X, Y, and Z about downloads.rdf, and possibly even incluse a link back to the issue article.--Np 02:26, 1 February 2006 (UTC)
Copied from the Knowledge_Base_changes discussion under New Proposal—Creating an article for each profile file:
However, a seperate article for each file seems like overkill, and biased towards more technically knowledgeable users. I'd prefer to see the effort put into writing more issues articles instead. However, if the consensus is to write a seperate article for each file then each file in the profile article should be linked to the corresponding article. Tanstaafl 22:35, 31 January 2006 (UTC)
I tend to agree that creating a separate article about each file in the profile might be "overkill" and (if patterned after the "preferences" articles) probably biased towards the technically-oriented. I was thinking more along the lines of concentrating on the files in the profile that come up all the time on the support forums when I agreed with the proposal (like downloads.rdf, mimeTypes.rdf and localstore.rdf) and then linking the new articles and existing articles that mention the files with "See also" references. However, on the original proposal, as written above, We could describe what the file does, the consequences of deleting it, etc. Another thing we could do us have Category: Profile files (Firefox) and Category: Profile files (Thunderbird), etc. so each application's users can have a list that applies to them without seeing the cruft.--Np 18:25, 29 January 2006 (UTC) ... If the idea behind writing Profile "files" articles is to replace the Profile_folder#Files_and_folders_in_the_profile section with a category listing, same as the Preferences article category listings are replacing various sections of the About:config entries article, eventually you are going to get down to the files with very little useful information to the normal user, and those articles will be solely for reference purposes. As a practical matter, these last file articles could just be "stubs" so that effort isn't wasted in finding all sorts of technical details about files that no one really needs. Alice Wyman 16:35, 1 February 2006 (UTC)
So the worst that could happen is "article no one needs". And the best that could happen is "article useful for the curious and technically-minded". Sounds fine to me. There's nothing wrong in including "reference" or "technical" information in the KB as long as it's not harmful towards less technically-oriented users. Being technically minded myself, I am interested in what random files in the profile do, so I'll contribute to documenting them, just like I do with the preference articles. It's not going to take away from me writing Issues articles because I don't know of any important enough issues to be documented that I haven't documented already. Plus it's my time to spend as I wish. Others who don't care about a certain file, as with anything else, don't need to contribute. --Np 16:57, 1 February 2006 (UTC)
I think the point being made was, why waste time and effort on articles with limited usefulness when it could be better spent on articles that benefit more users, such as "issues" articles. The assumption is that the pool of available editors is limited. That's why I suggested "stub" articles at the point of diminishing returns. Alice Wyman 17:29, 1 February 2006 (UTC)
You're also assuming that editors would otherwise spend time on writing issues articles. That's not true. I, for one, don't have any potential Issues articles floating around in my brain that haven't been written yet. Also, there's no boss around here so maybe I'd rather go do some forum work or extension work or whatever than write an issues article. Anyway, I don't see these articles taking a lot of time to write, based on the brainstorming for possible information. The editors will certainly realize that some files you need to yak about and other files a brief description will do, so I don't see a need to formalize that point - just leave it at their discretion.--Np 18:18, 1 February 2006 (UTC)
I don't want to split hairs over who made what assumptions. I only brought up the idea of "stub" articles because you had proposed such a detailed list of what to include in "profile files" articles under Talk:Profile_folder#Information included (brainstorming). No big deal. Anyway, instead of all this yakking someone should just go ahead and write that "downloads.rdf" or <number>.s" (passwords file) article and see what comes out. Alice Wyman 18:54, 1 February 2006 (UTC)
Yeah, I was going to give it a shot tonight.--Np 18:58, 1 February 2006 (UTC)
I took a shot: Profile Contents: localstore.rdf and bypassed the "wrong filename" and categorization issues. I know it's probably not what you were looking for but I was aiming it at typical users needing help with file corruption issues. Alice Wyman 05:54, 6 February 2006 (UTC)
Yeah, not what I was looking for. That info is still useful though, and it would be even more useful split up in appropriately named articles like "Bookmarks not saved". Have you seen downloads.rdf yet? I think most so far have agreed that it's more or less what we're looking for in these articles.--Np 06:24, 6 February 2006 (UTC)
Oops, I totally missed the downloads.rdf article and discussion... my only excuse is that I've been down with a terrible cold :-( ...I'll see what I can do to salvage that article if a "proper" localstore.rdf article gets written. Alice Wyman 07:52, 6 February 2006 (UTC)

Proposed hierarchy

Profiles
|-Profile contents (Firefox)
  |-bookmarks.html
  |-localstore.rdf
  |-chrome folder
  |-userChrome.css
  |-(...)
|-Profile contents (Thunderbird)
  |-localstore.rdf
  |-abook.mab
  |-chrome folder
  |-userChrome.css
  |-(...)

(What to do with folders?)

How about simpy adding "folder" to the end -- e.g., "extensions folder", "Mail folder", etc. (cf. "user.js file" and "prefs.js file"). That would distinguish the folders from the files in the category view, and it would keep people from landing in the extensions folder article when doing a search. --wintogreen 15:53, 30 January 2006 (UTC)
I was thinking more along the lines of "what to do with files in a folder?" Do we put it in as "chrome/userChrome.css", or do we make chrome a category with its files under it, or what?--Np 16:11, 30 January 2006 (UTC)
I see. I would list the filename by itself (e.g., "userChrome.css") and note in the article that it appears in a folder, and that's it. That way it'd be easy for people to find the file via a quick visual scan of the category. --wintogreen 16:27, 30 January 2006 (UTC)
I agree with Wintogreen. Firstly, I like the idea of adding the word "folder" to the end of article titles concerning subfolders of the profile folder. Secondly, I think that adding the folder path to the article title would be a bit of an overkill, as would creating mini-categories, unless filenames are not unique within the profile folder tree. In the latter case, we have no choice but to have some method of differentiation. (Ideally, we should keep things simple; "userChrome.css" has to be better than "chrome/userChrome.css". Incidentally, I'm not big on lumping userChrome and userContent together, although I can see the benefit of not needing to teach people CSS in two separate articles; what do others think?) --Mozcerize 16:37, 30 January 2006 (UTC)
I'd suggest seperate articles that link to each other, and maybe to something like http://www.mozilla.org/unix/customizing.html . Let that external link take care of teaching CSS. Tanstaafl 00:33, 2 February 2006 (UTC)

What about files such as parent.lock whose name differs by OS? I've found that you can make a redirect article that shows up in the category view but only if you categorize the article when you create it. If you come back later and try to add a category, it'll simply disappear from all category views. So, using redirects is not a good solution, but it would be nice to have all filenames (for the "same" file) show up in the category view somehow. --wintogreen 16:36, 30 January 2006 (UTC)

You might use a generic phrase that has the word lock such as such as lock files. A quick search for articles with lock in the title currently only returns "lock icon". Think about the comparable problem for *.s , *.w, *.mab, *.msf, *.src files and the fast load (XUL) files. The latter has been called "XUL.mfl" , "XUL FastLoad File" and "XUL.mfasl". At one time there also were "Invalid.mfasl" and/or "Aborted.mfasl" invalidated fast load files. Tanstaafl 00:33, 2 February 2006 (UTC)
Yeah, I guess that makes sense. We could insert a blurb at the top of the category page noting that some files will be listed alphabetically according to the filename extension/suffix or whatever. --wintogreen 09:20, 2 February 2006 (UTC)
I don't really like that idea because one of the major use cases of this category will be "what does file X do?". If you call an article "fast load file", how are people who don't know the names of the fast load file going to find it?--Np 16:45, 2 February 2006 (UTC)
How about something like "XUL fast load file" and then mentioning all of the possible filenames in the article? Its not ideal but "XUL.mfl" , "XUL FastLoad File" and "XUL.mfasl" all mention XUL so if you can't find the exact filename its an obvious article to take a look at.
Perhaps the real guestion is would we still have something somewhere like the "Files without specific names" section in the current profile folder article? It could link to the appropiate filename article. Don't forget that some filenames can be user defined (for example, if you import a dozen address books as .ldif files). Tanstaafl 09:47, 11 February 2006 (UTC)

Information included (brainstorming)

  • Name
  • Purpose
  • Its relationship to other files (ie whether it requires other files to work (like the password file), whether there are other places this info is stored, etc)
  • The consequences of deleting it
  • Whether it's possible/advisable/how to move it to another profile
  • Whether it's feasible/advisable to manually edit it
  • Versions that it appears in
  • Previous names/locations that did the same thing
  • Whether it exists by default
^ np, I would suggest that people start writing more articles about files (or folders) in the profile, for example, "downloads.rdf" and categorize them in whatever way is currently relevant, for now, since articles already exist about files in the profile (prefs.js and user.js, for example). Once a number of these articles are written, they can be categorized in a new "Profile Content" category once it exists. If you want to develop guidelines for future articles or rewrite current ones I would look for common issues among all of the existing "files" articles, to see what if any general "guidelines" should be followed. Also, is the "wrongtitle" template really needed for all file articles, such as User.js ("The correct title of this article is user.js file. It appears incorrectly here due to technical limitations in the wiki software.")? Alice Wyman 16:01, 30 January 2006 (UTC)
Yeah, people should feel free to write whatever articles they want. I just like to have guidelines before I dive in. As for the wrongtitle template, we wouldn't want people to name their files wrong... Maybe we can do a modified version like we do we the prefs articles?--Np 16:14, 30 January 2006 (UTC)
I particularly like the idea of discussing dependencies and the consequences of deletion. I would also like to discuss whether a give file is the only place where certain data is stored. For example, is "downloads.rdf" the only place that tracks download history, or does this info also get stored elsewhere, eg as temporary or persistant prefs. Ditto for cookies, history, passwords etc. --Mozcerize 16:25, 30 January 2006 (UTC)
The point about the "wrongtitle" template is a good one. I'd like to see its use discouraged. Tanstaafl 23:37, 31 January 2006 (UTC)
Why? I'd like to reiterate the point that I made elsewhere that, far from being confusing, the use of the wrongtitle template is essential in the case of these file articles where the capitalization is critical. Surely our first priority on the KB must be to keep things factually accurate. I think np's idea of creating a custom wrongtitle template for file articles is good; we can make it a little more accessible to non-technical users. --Mozcerize 12:57, 2 February 2006 (UTC)
I've made a similar template.--Np 17:03, 2 February 2006 (UTC)
You're right, the wrongtitle template is usefull for profile files. My prior comment was based on the standard wrong title blurb that I'm used to seeing. Tanstaafl 23:41, 6 February 2006 (UTC)

downloads.rdf as a test case

See downloads.rdf --Np 23:42, 1 February 2006 (UTC)

I've added some TB info to the article, changed the last header from "Possible issues" to "Related issues", and bolded the filename in the first sentence to make it (and the correct capitalization) stand out. --wintogreen 04:36, 2 February 2006 (UTC)
"Related issues" kind of implies "Issues related to this issue" to me, and the article doesn't describe an issue. But that just might be me.--Np 16:54, 2 February 2006 (UTC)

Now that we've got this file as a kind of test case, a few comments/suggestions that could pertain to future articles (--wintogreen 14:52, 2 February 2006 (UTC)):

  1. Some of the files that are shared between apps (esp. between Firefox and Thunderbird) might serve rather different functions or be accessed through different UI. (mimeTypes.rdf and cookies.txt are a couple others.) In the downloads.rdf article, even the seemingly straightforward phrase "download history" can have a very different meaning in the context of email (think POP), and a statement like "downloads.rdf is the only place where download history is recorded" can easily be misunderstood as well. I'm not sure what the best way to deal with this in the present article, but it's something we should try to keep in mind when writing/editing these articles. (And for the record, I don't know how the Suite records attachment-saving operations. Do they go into downloads.rdf as they do with Thunderbird?)
Agreed. I think we may need application-specific articles here. If we decide to link to them from pages like Profile folder, perhaps we should link to a disambiguation page where the user can choose which application he is interested in. --Mozcerize
That may be the best solution, and I don't think it would have to be used with more than a small handful of articles. --wintogreen 20:56, 2 February 2006 (UTC)
  1. The section about "Disabling": does it belong in this article? To my mind, it's essentially addressing a question about how to control the application behavior ("How can I stop Firefox from recording my downloads?"), and I thus think it should go into a regular article about managing download history, the Clear Private Data tool, or browser privacy. Even if there is no such regular article, it doesn't mean that the info should go into an existing "Profile file" article. More generally speaking, I think this relates to the concern Tanstaafl expressed earlier about the potential for these "Profile file" articles to the "lobotomize" the Issues [and other regular] articles.
    Yeah, I didn't think that belonged. Including a link to an article that describes it would be better.--Np 16:54, 2 February 2006 (UTC)
This section may not belong in the article. I put it there to test the water. I agree that it would be better to put it into another article about browser privacy. Regarding your other point, let's not forget that Issues articles are supposed to provide "a different view" on existing information. I would be unhappy to see useful information tucked away in Issues articles without being accessible via non--Issues articles. --Mozcerize
Every Issues article is is supposed to be categorized in a non-Issues category anyway, so that shouldn't be a problem... as long as we remember to follow our categorization rules. --wintogreen 20:56, 2 February 2006 (UTC)
  1. In the same vein, I don't think these articles should be categorized together with the regular end-user articles (currently this one is in the "Privacy and security" category). As reference articles, they should be treated essentially like the Preferences articles.
    Agree. --Np 16:54, 2 February 2006 (UTC)
I agree. In this vein, though, I don't see a problem if these articles are slightly more technical than the normal user support articles. --Mozcerize
Aye. I think if would be great if, for instance, some of these articles explained the anatomy of the file content. --wintogreen 20:56, 2 February 2006 (UTC)

Do we really need "Related mechanisms" if there are no related mechanisms? I think people would assume that when we say that the file contains download history that it is the only thing that contains download history. I don't know what the last three sentences are there for, either.--Np 16:54, 2 February 2006 (UTC)

If the point about Disabling is to be moved to another article, then so should the last three sentences. I can't make up my mind about the Related Mechanisms section. I think the fact that it is the only mechanism dealing with download logging is an important piece of information. --Mozcerize

"Usage" says to me "How can the user use this file", but that's not what it describes. I think this info should go into the intro.--Np 16:54, 2 February 2006 (UTC)

I agree. The problem is that we don't want the introduction to be too long. --Mozcerize

How these files will affect the profile folder article

To follow up on a previous comment by Alice, what's anyone thinking about how these articles will affect the present state of the profile folder article? Is the idea to simply linkify the filenames in the currently existing table? Personally, I hope so. I think it's fine the way the prefs listed in about:config entries are being removed from the list there once they're written up and put into Category:Preferences, since the pref titles themselves are generally descriptive enough to give you an idea of what the pref is for, but this isn't so true with the profile files. I like having the big list of files all on one page--each with very short description--so that you can scan through it quickly. --wintogreen 15:07, 2 February 2006 (UTC)

I was thinking of removing them from "profile folder", but I can see how the list might still be useful. One of the major points of this was to provide each application with a list of files that are used in it instead of having the user wade through a bunch of files that don't apply.--Np 19:03, 6 February 2006 (UTC)
I think that the Profile folder article and its lists should remain. There is no problem with having different paths to the same information. (The problem which originally inspired the categorization drive was having different paths—tips, faqs, and so on—which didn't lead to the same information yet gave no real clue as to where they did lead.) --Mozcerize 21:39, 6 February 2006 (UTC)

UI

How should we be listing the UI that affects any given file? Should we be listing all the elements the read or write from the file (for history.dat: History Sidebar, Clear Private Data, Location bar), or just those that provide an editing function (History sidebar), or should we describe what they do, and should we also describe preference UI related to the file...? I'm leaning torwards listing everything with a very short description of what its relationship to the file is.

  • History Sidebar (view and edit)
  • Clear Private Data (clear)
  • Location bar (autocomplete entries)
  • etc --Np 19:19, 6 February 2006 (UTC)
I too think that (all) directly relevant UI should be listed. --Mozcerize 21:40, 6 February 2006 (UTC)

Files outside the "Profiles" folder

I removed the entry for mailnews.js ("Mozilla Suite, Thunderbird" "Sets the default values for most preferences. Its in the defaults\pref directory in the thunderbird program directory") because I don't think that files or folders outside of the "Profiles" path should be listed here. Alice Wyman 15:12, 30 January 2006 (UTC)

I agree with this decision. --Mozcerize 16:21, 30 January 2006 (UTC)
I understand the logic of removing it, but it is hard to find usefull information and we don't have a good alternative place to tell somebody about it if they don't know the file exists. Perhaps we need an article describing the layout of the thunderbird program directory which identifies any usefull files (including ones you might need to tinker with if you have a problem), and then add it to "see also" in the profile article. Tanstaafl 22:22, 31 January 2006 (UTC)
Sounds like a good idea. We could link to it in the Installation directory article as well. --wintogreen 09:22, 2 February 2006 (UTC)

staged xpi folders

http://developer.mozilla.org/en/docs/Enhanced_Extension_Installation talks about a staged-xpis folder when installing extensions for Firefox. http://kb.mozillazine.org/Talk:Unable_to_install_themes_or_extensions_(Firefox) also mentions it. There is no mention of it in the profile article. I've never seen that folder for Thunderbird but a user who has problems getting an extension installed after upgrading to 1.5 claims Thunderbird has that folder, and the xpi files are sitting in it. Could somebody more knowledgeable about staged-xpis update the profile article? Tanstaafl 19:45, 6 March 2006 (UTC)

Vista

Could somebody who is running a Vista build add information about where Mozilla stores the profiles for that operating system? I believe it uses X:\Users\username\AppData\Roaming . See Finding the User Settings in Vista. Enough users are running betas/release candidates that its become an issue in the forums. Tanstaafl 18:31, 28 October 2006 (UTC)

Windows users section was complicated

The section talked about environment variables and searching and finding hidden folders. This was unnecessarily complicated, when a single sequence will work for 2000/XP/Vista users who didn't use a custom path.--Np 19:35, 7 February 2007 (UTC)

I think that the information is not too complicated and is needed for Windows users who want to use the Search feature to quickly locate hidden files that may be in the profile folder or even files and folders in the Local Settings folder, such as the Cache folder or XUL.mfl. Alice Wyman 22:13, 7 February 2007 (UTC)

The information I put in is much more clear. Simple step-by-step beats rambling about hidden files and environment variables. If you want to include additional information (how to get to the other files and folders mentioned, how to search instead) then add that information. Don't revert the article.--Np 22:52, 7 February 2007 (UTC)
I saw nothing wrong with the original version, which is why I reverted the article. I'll correct the misinformation (the path to the Thunderbird folder is not through the Mozilla folder; Windows Vista uses the AppData folder, not "Application Data") and I'll add back the important information users need to show hidden files and folders and to do a Windows Search. Alice Wyman 23:29, 7 February 2007 (UTC)
Here are the things wrong:
  • "If you cannot find your profile folder" - the article hasn't even told the user to try yet, so this phrase doesn't make sense. Is this section a "before you start" section, or is it a "how to quickly get things done" section? It seems to trying to be both. I'd prefer a "how to quickly get things done" section.
  • Why link to an article about environment articles? Why even mention "environment variable"? Those that would care already know, those that don't care would just get confused.
  • Why suggest they type in Mozilla/Firefox or Thunderbird/Profiles? People know how to navigate folders, let them do the easy thing.
  • Why suggest doing a search at all? If the user is trying to find a specific file, they'd likely have more luck just browsing to the folder and finding it in the list. It's an extra level of unnecessary complexity, what with the hidden file settings.
  • Why is the show hidden files info a bullet point?--Np 02:38, 8 February 2007 (UTC)
  • If you cannot find your profile folder....because this happens alot. Remove if you must.
I don't dispute that some people can't find their profile folder, I'm just saying that it doesn't make sense where it is in the article because at that point the user hasn't even started trying. --Np 16:20, 8 February 2007 (UTC)
  • Why link to an article about environment articles? Why even mention "environment variable" Because this is a Knowledge Base and we want to provide links for users who may want additional information.
There's no problem with including extra info, except when you're going to potentially confuse people with it. I've kept the link for people who are interested, but taken out any discussion of environment variables.--Np 16:20, 8 February 2007 (UTC)
  • Why suggest they type in Mozilla/Firefox or Thunderbird/Profiles? because it is a shortcut method to get to a desired folder instead of opening up the Application Data folder and then scrolling through it to find the "Thunderbird" folder or the "Mozilla" folder, and because we refer back to the section when we refer to, for example, %APPDATA%\Mozilla\Firefox\Profiles\<Profile name>\ (see above)
How many people who would want to use that method don't already know that they could?--Np 16:20, 8 February 2007 (UTC)
  • Why suggest doing a search at all? Because people will do a search on their own and will not be able to find the file they are looking for. This happens a lot when people are told to delete the "downloads.rdf" file, do a Windows search, then report that they can't find it. In other cases, a KB article will tell people to do a Windows search and link here for the instructions.... The Bookmarks article tells people: You can use your operating system’s file and folder search feature to locate your stored bookmarks, or you can open the profile folder and look through its contents.....then links here for instruction on viewing and searching hidden files and folders. Other articles may also do this. Do you want to remove these instructions and then find and update every article that links to it? I was able to find the specific instructions to enable viewing hidden files and folders in Vista, by the way, and added it to the article. It would be great if a Vista user would look over the section and add any necessary changes.
OK, so the problem was that the two methods were jumbled. I've changed it around to make it clear it's an either-or, either you can do APPDATA, or you can do the hidden folder thing and then do a search.--Np 16:20, 8 February 2007 (UTC)
  • Why is the show hidden files info a bullet point? There are two bullet points now, since I added one for Windows Vista. I'm guessing your objection was to the single bullet, which I agree was probably not needed. Alice Wyman 14:26, 8 February 2007 (UTC)
To search, it is not sufficient to enable viewing of hidden files and folders. You must enable SEARCHING for hidden files and folders. Even experienced people make this mistake.
Look at the directions more closely. Enabling searching for hidden files and folders is exactly what it's suggesting for Windows XP and Vista (I've confirmed that enabling viewing is not required on XP). It's only suggesting enabling viewing of hidden files and folders for Windows 2000.--Np 18:42, 8 February 2007 (UTC)
We're going around full circle though. Much of this does not apply to Win 98. Fixed. --AnotherGuest. 8 Feb 07
Yeah, we need Win 98 instructions.--Np 18:42, 8 February 2007 (UTC)
I added back the steps to view hidden files and folders, edited the Search instructions and added a reference for Vista. I'm also copying the discussion from Talk:Lost_bookmarks#Background below, regarding the Windows 2000 and XP search instructions which keep getting mixed up. Alice Wyman 23:31, 8 February 2007 (UTC)
AnotherGuest, you added the following sentence to this section: "Note also that for searching it is not sufficient to check "Show hidden files and folders" in Windows Explorer. You must set this option in the Search box." However, this claim does not appear to hold true on my Windows 2000 system. Please could you or somebody else confirm that this is true on WinXP, and if so, amend this article and the Profile Folder article. (If it really is true for WinXP then that O/S is even more of a bad joke than I had thought....) Cheers --Mozcerize 16:14, 12 July 2006 (UTC)
I can confirm that, on Windows XP, it is not sufficient to select "Show hidden files and folders" in Windows Explorer. If I UNcheck the "Search hidden files and folders" option and search for "localstore.rdf", for example, a Windows search will NOT find the copy in my C:\Documents and Settings\Alice\Application Data\Mozilla\Firefox\Profiles\default.cta folder, even though "Show hidden files and folders" is selected in Windows Folder Options, View tab. If I DO check the "Search hidden files and folders" option, it will find the Application Data copy. I amended this article to add "in Windows XP" after Note also that for searching..... I similarly amended the a Profile folder article. Alice Wyman 14:29, 13 July 2006 (UTC)
Great, thanks Alice. Just out of interest, will WinXP find hidden files if you check the option in the search area but do not have Explorer set up to show hidden files in general? (Is the option in the search area even available if Explorer is not set up to show hidden files in general?) --Mozcerize 14:34, 13 July 2006 (UTC)
If I select "Do not show hidden files and folders" in Windows Explorer Folder Options, View tab (so that the "Application Data" folder does not appear under C:\Documents and Settings\Alice), a Windows search will STILL find the localstore.rdf file in my C:\Documents and Settings\Alice\Application Data\Mozilla\Firefox\Profiles\default.cta folder, as long as "Search hidden files and folders" is checkmarked in the Search window. The options for showing and searching hidden files and folders seem to be independent in Windows XP. Alice Wyman 14:51, 13 July 2006 (UTC)
I notice that it still refers to Win 2000/XP re searching for hidden files. I am reluctant to make changes because I cannot check for Win 2000. My assumption is that it's better to leave a warning that may not apply, rather than omit a warning that does apply.--AnotherGuest. 17 July 2006
Done. --Mozcerize 12:33, 18 July 2006 (UTC)

AnotherGuest, you just changed the article as follows: Windows 2000/XP users will need to enable viewing of hidden files and folders in the Search box itself. This is not true, as was already explained by Mozcerize above, last July (in Windows 2000, it is sufficient to select "Show hidden files and folders" in Windows Explorer, which also enables searching). I think that all this explanation here is unnecessary since the information is already linked here. Alice Wyman 18:46, 19 October 2006 (UTC)

Right. I didn't mean to change the 2000 bit. I'm just tired of going around in circles about this with people who claim exalted status but who skim this section (or not) and can't find a file. So I made it bold and simplified the language a little. Also made it a correct statement -- in Win XP it's not necessary to unhide the directory to find it. Also added back a reference to a simplified search procedure. Some people like to direct people to use %APPDATA%, and it's nice if the existence of the method is mentioned here. AnotherGuest. 19 Oct 06

For Windows users - Vista

On Vista, the Start -> "Run" box is not shown by default. You can use the "Start Search" box instead [3] [4]. Start -> Start search -> %appdata% does work on Vista, based on what I found here . See also http://www.mozilla.org/support/firefox/profile#appdata Alice 18:48, 2 March 2007 (UTC)

Density

The information presented under "Where is my profile folder" is quite dense - there's a lot of info packed with a lot of technical information. The information is important, but we have to realize that most people just want to quickly find their profile. We need to find a better way to split this out so people can find the information they're looking for without having to wade through the information they're not. A few points to remember:

  • The majority of people have their profile in the default location
  • The majority of people who don't have their profile in the default location already know where their profile is
  • The majority of people are on Windows
  • The majority of people are here to find their profile folder in order to do something else (back up their bookmarks, delete a file, etc.)

So here are my suggestions:

  • Split this article into separate articles for each app. Keep this article around like we did for Standard diagnostic. This way, we can greatly reduce the amount of noise people have to read through. If duplication of content is a concern, we can create templates for specific information.
  • In each article, create a section called "Finding the profile folder" with subsections for each OS. These subsections will include complete instructions on how to find the profile folder. This way, users will only have choose the correct heading and they will be presented with all the information they need.
  • Continue to present simple information first, then present detailed information if necessary.

--Np 16:41, 18 May 2007 (UTC)