Closed Bug 310953 Opened 20 years ago Closed 20 years ago

Preferences not saved between sessions

Categories

(Camino Graveyard :: Preferences, defect)

Product:
Camino Graveyard
Component:
Preferences
Platform:
PowerPC
macOS
Type:
defect
Priority:
Not set
Severity:
minor

Tracking

(Not tracked)

Status:
RESOLVED WORKSFORME

People

(Reporter: MarketArt, Assigned: mikepinkerton)

Details

User-Agent: Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.8b4) Gecko/20050914 Camino/1.0a1 Build Identifier: Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.8b4) Gecko/20050914 Camino/1.0a1 The particular preferences that I need saved, and that I have to set every time I launch Camino, are (in the Tabs pane) "New windows and tabs: Load in the background" and "Link from other application: Opens in a new window", and (in the Downloads pane) "Open downloaded files", the last of which I would like to stay unchecked. Reproducible: Always Steps to Reproduce: 1. Launch a new Camino session. 2. Open Preferences and change any of the settings mentioned above. 3. Close Preferences and exit Camino. 4. Relaunch and check Preferences to see if your change was kept between sessions. Actual Results: Those particular settings all reverted to their default. Other Preferences remain changed as set. Expected Results: Kept the settings as they were before quit-relaunch. I have seen this bug through several versions.
Are you sure you don't have something in user.js that's overwriting the prefs. in prefs.js? (At least this is how it works with Firefox...) Also, do you have write permissions to your profile directory?
I have never had and don't currently have a user.js file. I have full read and write access to ~/Library/Application Support/Camino, as well as to prefs.js, incidentally. I haven't deleted any of the 312 Preference back-up files (prefs-1, prefs-2, etc.). I have this problem on two separate systems with two different accounts, one an administrative account and the other a user account, on each.
If you have lots of preference file backups then something is making the file unwritable to Camino. Maybe this is like bug 294584.
I don't know. I don't think so, because I am using Jaguar (10.3.9) and have no Spotlight control panel.
can we get a list of which prefs behave this way?
If you delete those prefs backup files, do new ones get created? Also, have you checked the owner and permissions on prefs.js? It sounds like it's not writable.
I just went through every pane and every setting (except for Advanced buttons) and changed them all. Nothing stuck, except for "Save downloaded files to:" in the Downloads pane. On relaunch, the folder given was the new folder I had picked. Other than that, every setting reverted to what it was before (not the default). It must be a rights issue, but I can't figure out what. As noted below, I have full R/W rights to ~/Library/Application Support/Camino, as well as to prefs.js and every other file and directory in there. I'm sorry to say, though, that contrary to an earlier note, I just verified that this problem only occurs with my own regular user account, that is not an administrative account. It does _not_ occur with the account with administrative rights that I don't normally use. That account saves Preferences changes between sessions. About those back-up "prefs" files: two are created every time I exit Camino, plus one for every time I open the Preference pane. If I delete them manually (I don't know if they're ever deleted automatically), two will reappear if all I do is launch and then immediately quit. If I launch, open Preferences, close Preferences without changing anything, and then quit, three are created. If I happen to open Preferences six times, eight would be created (I tested this).
Summary: Some preferences not saved between sessions → Preferences not saved between sessions
Please run the Teminal app, and type cd Library/Application\ Support/Camino ls -la and paste the output here.
MAmiMac:~ GMC$ cd Library/Application\ Support/Camino MAmiMac:~/Library/Application Support/Camino GMC$ ls -la total 1640 drwxr-xr-x 19 GMC GMC 646 4 Oct 17:51 . drwx------ 13 GMC GMC 442 26 Aug 16:10 .. -rw-r--r-- 1 GMC GMC 6148 4 Oct 17:51 .DS_Store -rw-r--r-- 1 GMC GMC 0 14 Mar 2005 .parentlock drwxr-xr-x 2 GMC GMC 68 13 Jul 19:18 Cache.Trash -rw-r--r-- 1 GMC GMC 604 27 Jul 16:50 SearchURLList.plist -rw-r--r-- 1 GMC GMC 88812 4 Oct 17:51 bookmarks.plist -rw------- 1 GMC GMC 65536 4 Oct 17:51 cert8.db drwxr-xr-x 3 GMC GMC 102 14 Mar 2005 chrome -rw-r--r-- 1 GMC GMC 22292 27 Sep 14:58 cookies-1.txt -rw-r--r-- 1 GMC GMC 22319 3 Oct 17:46 cookies-2.txt -rw-r--r-- 1 GMC GMC 22170 4 Oct 17:28 cookies.txt -rw-r--r-- 1 GMC GMC 191 30 Sep 16:13 downloads.plist -rw-r--r-- 1 GMC GMC 542816 4 Oct 18:02 history.dat -rw-r--r-- 1 GMC GMC 60 28 Mar 2005 hostperm.1 -rw------- 1 GMC GMC 16384 4 Oct 17:51 key3.db -rw------- 1 GMC GMC 7901 29 Sep 17:21 pluginreg.dat -rw-r--r-- 1 GMC GMC 1759 9 Mar 2005 prefs.js -rw------- 1 GMC GMC 16384 14 Mar 2005 secmod.db I included the first two lines of the session as well. Note that none of the "prefs" back-up files appears here, because I haven't exited Camino yet.
Aside from the group on those files being "GMC" instead of "staff", they look OK to me....
It may be that my own (two) OS X installations are somehow unique, or just that I hardly do any command-line stuff; but I have never seen the "staff" group on anything, and creating a new user in System Preferences always creates a new group of the same name at the same time, with the new user as the sole member of the group. I doubt it's relevant but thought I should mention it.
I just created a new user and the same thing happened (user=group); must have changed in 10.3 and above. So strike that theory. Do you have any 3rd-party indexing software? Or Sherlock (does Sherlock still create indexes on 10.3.x; somewhere I've seen the "old" indexing UI still around)? FileVault?
I don't use third-party indexing software, and never have. I did try Sherlock for a while, but my version has no file-indexing channel and I never used it for this purpose (I also abandoned it completely at least a year ago). I do, however, use FileVault, and have since the beginning. What should I do to test it to see if it's involved in the problem?
There have been a couple of recent reports of strange behavior in association with FileVault and non-admin users (something about Camino wanting the admin user's password on launch? Mark, what was the issue with that?), so it's just a guess. Ignoring FileVault for a minute, there are two things I'm not sure have been tried: 1. Move aside your existing Camino folder from the problematic user's ~/Library/Application Support folder. Restart Camino (which will create a new folder), set a few prefs, and see what happens. Do the prefs stick? Do additional prefs.js files get created? 2. If prefs don't stick and additional files get created, make sure you've quit Camino, then delete prefs.js and all but the most recent of the prefs-N.js files. Rename the most recent prefs-N.js to prefs.js, restart Camino, set a few prefs, and see what happens. Do the prefs stick now, or do additional prefs.js files still get created?
(In reply to comment #14) > There have been a couple of recent reports of strange behavior in association > with FileVault and non-admin users (something about Camino wanting the admin > user's password on launch? Mark, what was the issue with that?), so it's just > a guess. This isn't likely to be a FileVault problem, or at least it's not likely to be *THAT* FileVault problem. Guy, could you check to see if the file is locked in the Finder? Go to ~/Library/Application Support and Get Info on the Camino folder. The Locked checkbox shouldn't be checked. Do the same for the prefs.js file inside that folder.
#1 worked (moving aside ~/Library/Application Support), and just to make sure I let it go for a few days of use, during which I closed and re-opened Camino several times. The multiple prefs.js's are no longer appearing. All preferences now persist as expected. It was a minor annoyance to recreate some of the preferences, but that's not important. I still don't know what initially caused the problem. Is the following a clue? When I moved the Camino folder in Application Support, what I actually did was to first move it to the Desktop, then make an archive of it, then drag it to the Trash, and finally Secure Empty the Trash. This all went fine until Secure Empty reached prefs.js, which it couldn't delete because _the file was locked_. Now I had checked this file a while ago (before this reporting began), and neither it nor the parent Camino folder were locked. And just to make sure I wasn't inventing this memory, I decompressed the archive I'd made and checked prefs.js and the parent folder. Neither was locked. All of the above took place with Camino closed; how did prefs.js wind up being locked once it made it into the Trash? In any case I don't know much about these matters, and have a kind of patch if the problem crops up again. If it does crop up again, I will note it immediately and try to determine the cause, instead of letting it go. Thanks for all the help and let me know if there's anything else I can do. (In reply to comment #14) > … > > Ignoring FileVault for a minute, there are two things I'm not sure have been tried: > > 1. Move aside your existing Camino folder from the problematic user's > ~/Library/Application Support folder. Restart Camino (which will create a new > folder), set a few prefs, and see what happens. Do the prefs stick? Do > additional prefs.js files get created?
Resolving worksforme. zip archives created in the Finder by File:Create Archive or the contextual menu equivalent don't store attributes like "Locked." Your prefs.js file somehow wound up locked, and it happened long before you moved it to the trash.
Status: UNCONFIRMED → RESOLVED
Closed: 20 years ago
Resolution: --- → WORKSFORME
You need to log in before you can comment on or make changes to this bug.