Talk:Profile folder

From MozillaZine Knowledge Base

(Difference between revisions)
Revision as of 00:33, 2 February 2006
Tanstaafl (Talk | contribs)
(Proposed hierarchy)
<-- Previous diff
Revision as of 04:36, 2 February 2006
Wintogreen (Talk | contribs)
(Information included (brainstorming))
Next diff -->
Line 63: Line 63:
::::The point about the "wrongtitle" template is a good one. I'd like to see its use discouraged. [[User:Tanstaafl|Tanstaafl]] 23:37, 31 January 2006 (UTC) ::::The point about the "wrongtitle" template is a good one. I'd like to see its use discouraged. [[User:Tanstaafl|Tanstaafl]] 23:37, 31 January 2006 (UTC)
See [[downloads.rdf]] --[[User:Np|Np]] 23:42, 1 February 2006 (UTC) See [[downloads.rdf]] --[[User:Np|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. --[[User:Wintogreen|wintogreen]] 04:36, 2 February 2006 (UTC)
==Files outside the "Profiles" folder== ==Files outside the "Profiles" folder==

Revision as of 04:36, 2 February 2006

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, has the user delete several files in the profile.
Looking at the articles in 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 " 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)

Proposed hierarchy

|-Profile contents (Firefox)
  |-chrome folder
|-Profile contents (Thunderbird)
  |-chrome folder

(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 . 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)

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)

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)

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)