MozillaZine

Talk:Profile folder

From MozillaZine Knowledge Base

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)


Contents

"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)

You could create a new, "easy" profile folder article for Firefox users and see how it works out while keeping this article intact, similar to how we added a new Creating a new Firefox profile on Windows article while still keeping the Profile Manager article. Just a thought. Alice 18:29, 18 May 2007 (UTC)
Creating a new Firefox profile on Windows wasn't created as a new trial version of Profile Manager, it was created as an article about creating a new profile. I'm suggesting here the same content, only better.--Np 18:00, 22 May 2007 (UTC)
Now you're saying you want to keep the same content, only improve it? Your earlier suggestion was, Split this article into separate articles for each app. Keep this article around like we did for Standard diagnostic....<snip>...In each article, create a section called "Finding the profile folder" with subsections for each OS. If you want to "keep this article around" like we did with the Standard diagnostic, that article has no content other than linking to the spun-off articles. I see no problem with the content, unless it's simply the length. It's not hard to navigate, in my opinion, and many articles link here, particularly to the Profile_folder#Where_is_my_profile_folder.3F section and the subsection Profile_folder#For_Windows_users. If you absolutely must shorten it, why not spin off the sections Profile_folder#Managing_profiles and Profile_folder#Files_and_folders_in_the_profile? Alice 19:22, 22 May 2007 (UTC)
Same content, but not in the same place. The problem with the current form, as I said above, is the signal to noise ratio. All the info here is useful to someone, but by trying to be useful to everyone, most of the information in this article is not useful to any given person. Regarding your alternate split, Windows users might want to read about how to manage profiles, but they definitely won't want to read about where Macs store their profiles.--Np 20:21, 22 May 2007 (UTC)
I like Np's suggestions. Too many users eyes just glaze over with dense articles like this one. Please keep in mind that many users are still adjusting to the idea that their data is actually stored in a profile rather than within their program directory when they read the article and sometimes we're dealing with users who have difficulty even keeping straight the name of the application.
I think Alice's point about many articles link to sections within this article is mainly an issue for articles that are written for multiple applications. I suggest we decide on a case by case basis whether its more appropriate to leave the existing link or to decide which application most readers of that article are using and adjust the link accordingly. If each profile folder article has links to the other ones I think people will cope.
If Np creates a profile folder article for Firefox I'll use it as a model to create one for Thunderbird. Tanstaafl 21:53, 22 May 2007 (UTC)
OK, I see. You want to keep the same content, except remove it from this article and include it in separate articles covering each application, and maybe another article for the Files and folders or stub articles for each, whatever. Like I mentioned before, it adds an intervening link for articles that now go to profile folder and people will no longer get directed to specific article sections like Where is my profile folder? and For Windows users which are linked in many other articles, unless someone goes back and replaces those links with one for each application article, which may involve rewriting the article, if it deals with multiple applicztions. If you want a separate article for Firefox users so that it can be migrated to the new mozilla.com KB that is in the works, go ahead, but please leave this article intact (or at least, just spin off the "Files and folders" section to a separate article) and just improve this article :-) ... I also dislike the trend of creating new articles for a single application, if just a little more effort would make it apply to more than one, as was brought up in Knowledge_Base_changes#Application_specific_articles. Moreover, In-house_style (under Articles that apply to more than one application suggests writing articles that apply to more than one application as a general rule, unless that would "make the article excessively messy". The old Standard diagnostic was indeed messy, but that's not the case here. Alice 22:44, 22 May 2007 (UTC)
Regarding your alternate split, Windows users might want to read about how to manage profiles, but they definitely won't want to read about where Macs store their profiles. You lost me there. My "alternate split", assuming we just want a shorter article (and I'm not convinced that we do) was basically to spin off the Files and Folders section to a new article. The Files and folders section talks about each file or folder in the profile, regardless of where the profile is stored. Your suggestion for separate articles for each application would list the profile locations for Firefox under different Windows versions as well as Mac and Unix, wouldn't it? You said, In each article, create a section called "Finding the profile folder" with subsections for each OS. Isn't that what we do now, in the different sections fo each application? By the way, about the short "Managing profiles section, it's not all that important, except for the Caution about deleting renaming or moving the profile folder, which should be kept somewhere, since the "See also" section already links to the information. Alice 22:44, 22 May 2007 (UTC)
While users will have to click on a link to choose their application in my proposal, they still have to click on a link to choose their application in the current situation. The issue is not splitting out content for any new KB, and it's not the length of the article. It's the fact that the majority of information provided in the current article is irrelevant to any given user.--Np 00:21, 23 May 2007 (UTC)
It might help if you do a really quick and dirty version for Firefox in the sandbox (don't worry about errors, typos, cosmetic details etc.). Its much easier to evaluate something that you can see. Tanstaafl 02:39, 23 May 2007 (UTC)
I also think a proposed article would help, or just create a new "Profile folder - Firefox" article so that we can see what you have in mind. Alice 11:54, 23 May 2007 (UTC)
they still have to click on a link to choose their application in the current situation. No they don't, they can scroll down. My main complaints with your proposal include 1) We often link to profile folder or profile for a definition, which is contained in the article's intro. Now the user will have to click on another link to find out what we mean by a Firefox "profile", unless you keep the intro. What about the "Files and folders" section? If you keep the intro why not also include that section? You weren't planning on separate "files and folders" sections in each spun-off article, were you? 2). There will be many broken links to Profile folder#For Windows users which we now include in articles to explain how to find or search hidden files, such as in the Bookmarks article. ... the majority of information provided in the current article is irrelevant to any given user The same could be said about other articles such as Problematic extensions but I don't really think it should be broken up into separate articles such as "Adblock issues", "NoScript issues" "Google Toolbar issues", etc., especially if it is reformatted to include a TOC. Alice 11:54, 23 May 2007 (UTC)
Yes, they can also scroll down, but the point is it's a two step process in both cases - pick an app, pick a platform. I don't see any reason why we couldn't keep the intro. I'm not sure what I want to do with Files and folders, whether to split that too into app-specific articles, or include it too, or have it in its own article. Personally, I'd rather have it replaced as described below. Links to certain portions of this page won't be broken per se, they'll just go to the most general page if we can't be more specific as to which app it is. This situation is different than splitting up other articles such as Problematic Extensions in that it's a simple choice for the user to pick their application, whereas users might have multiple extensions in the list which may or may not be the source of their problems.--Np 14:33, 23 May 2007 (UTC)

I've set up an initial version at Profile folder - Firefox. I think it roughly meets the guidelines I outlined - the instructions are very simple and are geared towards the majority of people, but information is still included for the minority. I think the sections that don't have step-by-step instructions could probably use them, though, and I'm still not sure what to do with the files and folders part.--Np 15:17, 23 May 2007 (UTC)

I like what you have so far. Now that you've gotten rid of a lot of the distractions it will probably be easier to tweak the instructions. I suggest you get rid of any non-Firefox folders in the folder section, move the file section to another article and replace it with a abbreviated section that describes just the files that most users look for. Whatever that list of files is, it should be short.
I suggest you keep the "Files outside the Profiles" section in the Firefox profile article, get rid of the "Application" column in the Firefox profile article, and replace it with a Version column in the supplementary article. Tanstaafl 23:35, 23 May 2007 (UTC)
The way you've got it, partial information on files is in three places - the Category:Profile contents (Thunderbird), Profile folder - Thunderbird, and Files and folders in the profile - Thunderbird. I don't think all three are necessary. Two would be good - a quick overview of important files and a detailed description of each one.--Np 17:37, 25 May 2007 (UTC)
I've set up Profile folder - SeaMonkey. I didn't know what to do about the "Files and folders in the profile" section so I just added the whole set, following np's lead. Alice 23:00, 25 May 2007 (UTC)
I view Category:Profile contents (Thunderbird) as reference articles (just like the reference articles about a single preference), not user articles. None of them appear to be written for Thunderbird, they all appear to be multi-platform, which means they're actually either Firefox-centric or browser-centric. Frankly, I'd prefer the four profiles contents categories to be replaced by one category since they're just reference material.
If I eliminated Files and folders in the profile - Thunderbird then I'd lose the complete overview and either have to create at least 49 articles or reuse many articles that are browser-centric. There is little need for a article on every single file. Frequently all you need to know about a file is whether its the right one to delete to solve your problem.
The problem is because we're trying to deal with the needs of multiple classes of users. I interpret (that doesn't mean I'm right) what you're suggesting as targeting the two extremes. I'm trying to optimize the material for the majority of users, and feel thats better served by getting more issues or user articles, not more reference articles. I'm making a tradeoff based on the assumption that we don't have enough resources to keep everything uptodate and/or write all of the articles that we wish. The downside is that some technical users might have to read a reference article that was Firefox-centric. I think thats acceptable because I'm trying to increase the odds they don't have to resort to a reference article, and they're the ones who would have the least trouble dealing with a article that wasn't written for Thunderbird. Tanstaafl 00:06, 26 May 2007 (UTC)
I understand that the different versions target different users and are for different purposes. I'm suggesting we keep the individual articles as references, and then pick one way to present the files in a support context, not two.--Np 02:57, 26 May 2007 (UTC)
I've set up an initial version at Profile folder - Firefox. <snip> ... and I'm still not sure what to do with the files and folders part. ......As I see it, a final decision hasn't been made to move the "Files and Folders in the profile" section to each application article....or has it? Right now these articles are in the draft state, even though they've been categorized. Like I said, I copied the files and folders section for all applications to the SeaMonkey article, even though some of the entries don't apply to SeaMonkey. I don't think the list should remain that way in the final version; if we do keep the list of files and folders within each application article then it should be customized for that application, as Tanstaafl did, but I don't think that we should maintain two lists for each application. I think it's better that the entire list for that application should be in the "Profile folder - <app>" article, if we go that route. We already maintain a list of important files and folders in the Migrating settings to a new profile article, and we link there (it covers all three applications right now, although you may be planning to split up that article also?). We still have the option to leave the "Files and folders" section in the current profile article (my preference) or to create a separate Files and folders in the profile article that applies to all applications (my second choice). Alice 02:13, 26 May 2007 (UTC)
I view Category:Profile contents (Thunderbird) as reference articles (just like the reference articles about a single preference), not user articles. <snip> Frankly, I'd prefer the four profiles contents categories to be replaced by one category since they're just reference material. I also agree with Tanstaafl that these are basically reference articles. If we don't plan to direct users to the "Profile contents (<app>)" category page then I don't see why the articles shouldn't be merged into a single category, regardless of the original agenda for creating and categorizing those articles (see above). Alice 02:13, 26 May 2007 (UTC)
The categorization is simply a way to put the articles into different "views" for each app without duplicating content. I don't see any disadvantage in keeping the categorization.--Np 02:57, 26 May 2007 (UTC)

Are we good with what we've created? Should we replace this article with links to the app-specific articles, and then fix any non-ambiguous links to this article to point to the app-specific ones?--Np 15:43, 5 June 2007 (UTC)

I'm fine with the SeaMonkey article, which I recently edited to remove all non-SeaMonkey profile files and folders, same as was done with the Thunderbird article. I think that the Firefox article should also be limited to Firefox files/folders unless you have a particular reason to keep the combined list. That leaves Sunbird.... do you want to incorporate that with Firefox, create a new Sunbird article, or just eliminate Sunbird? As for what to leave in the current article, I would suggest keeping the Intro and expanding it to include, Caution: The installation directory also includes a "profile" folder but this folder contains program defaults, not your user profile data. Use the information in the articles linked below to find your profile folder. and then add the article links. Alice 17:52, 7 June 2007 (UTC)
Also, once this article is reduced to an Intro and app-specific links, I was thinking to create a new article, Finding the profile folder on Windows which I started here and maybe include some screenshots for Windows users that need extra help, then link it to this article. Alice 17:52, 7 June 2007 (UTC)
I'm fine with the three application specific versions of the profile folder article, and would like to see links modified to use the appropriate one. "That leaves Sunbird" - what about Camino and Minimo? Perhaps we should modify the (generic) profile folder article to be the catchall for the less popular applications. If somebody interested in writing articles for Sunbird ever wants to split off a separate article for Sunbird and maintain it more power to them. One reason for a catchall article for just the less popular applications is its probably going to always be slightly out of date since we don't have any editors that write a lot of articles for those applications.
I didn't find Alices proposed article much more usable than the SeaMonkey profile folder article, even though it was shorter. Most of the extra length was in the file listing at the end which a windows user trying to find the profile location normally wouldn't even see (since they'd have to scroll/page down to it). However, I like the idea of screen shots. I suggest you turn the proposed article into a supplementary article (for those who have problems with the normal article) that consisted almost entirely of screen shots showing step by step in exquisite detail how to find a profile. i.e. something thats long and not your first choice, but will guarantee that even the most computer illiterate user could find the profile. Tanstaafl 22:54, 7 June 2007 (UTC)
I'll remove the non-Firefox files and folders from the Firefox article.
Regarding Sunbird and other apps, I think we should address them in this article very briefly. We could include the intro, the links to the app-specific articles, and then say that for other apps, profiles will be in the following locations. No special %APPDATA% shortcuts or anything, just list the paths. If someone wants to come along and write articles for other apps, then we'll just include it in the intro.
I don't necessarily see the need to include the caution, because woundn't that caution be in the app-specific articles as well?
I think the caution would be a good idea to tip off novice users that they need to look at the linked articles. Otherwise, some users will just assume that the "profile" folder in the program files is the profile folder for their user data. Lots of users hate to click links and just getting many of them to click the Profile folder link is hard enough. Once they get to that article, a "caution" will help them avoid this common mistake that you see made so many times on the forums, since the revised profile folder article won't have any information about the "real" profile folder location. Alice 01:10, 8 June 2007 (UTC)
I agree with tanstaafl regarding the proposed article and the screenshots. We could create a hand-holding version for the most common user, just like the creating a profile article.--Np 23:13, 7 June 2007 (UTC)
I'm working on my proposed "Finding the profile folder on Windows article, little by little and I've just added a couple of screenshots. I was thinking along the lines you both suggest, turning it into a supplementary article for Windows users who need extra help, along the lines of the Creating a new Firefox profile on Windows article. Alice 01:10, 8 June 2007 (UTC)

Profile files articles

I suggest we move whatever info we have here on profile files that don't already have their own article into a stub article, then replacing the info here with a link to the category. There's no use having partial information in two places.--Np 16:44, 18 May 2007 (UTC)

I disagree. Why create a whole lot of stub articles when we probably won't have enough information to expand them? I think that replacing the list with stub articles would also discourage people from adding information on new files or folders that come about due to program updates. I think people are much more likely to add entries to a list than create new articles or stubs. If you just want to shorten this article, I think it would be better to move the Files and folders in the profile section to a new article and keep the list intact. Alice 18:01, 18 May 2007 (UTC)
We do have enough information to expand them, it's just that no one has done it yet.--Np 18:07, 18 May 2007 (UTC)
Well then, keep the "Files and folders in the profile" list together until you do create new articles for each entry, similar to what we do with the About:config entries while adding new articles to Category:Preferences. Alice 18:32, 18 May 2007 (UTC)
That's what I'm proposing, except rather than creating a full article for each one, we create stub articles and then expand on them.--Np 18:36, 18 May 2007 (UTC)
I don't see the point of creating a bunch of "stubs" if a brief description is already included in the current list of files and folders. I'd prefer to keep a list, since I think that editors would probably be more likely to add a new entry to a list rather than create a new article or stub, as I mentioned above. I also think it's more "user-friendly" to have a list that includes a short description and a link to a complete article (if one exists), rather than a bunch of stub articles on a category page whose names don't make much sense. At least with a list people can simply look at the file or folder description, then go to the linked article if they want more information. This idea of a separate article for each file was discussed before (see above) and it was brought up that having a separate article for every file in the profile is probably "over-kill". Alice 19:14, 18 May 2007 (UTC)
I agree with Alice. I also think its a bad idea to make two major changes at the same time. Tanstaafl 22:07, 22 May 2007 (UTC)