Audacity Forum

Gale Andrews wrote:

DJDemon wrote:the "old" seettings directory did have the correct permissions

Have you done Verify Disk and Repair Permissions yet? It does not matter what GetInfo says if your permissions are messed up.

Gale

That only verifies and repairs ***some*** system permissions. Doesn't do a thing for user owned data...

cyrano wrote:

Gale Andrews wrote:

DJDemon wrote:the "old" seettings directory did have the correct permissions

Have you done Verify Disk and Repair Permissions yet? It does not matter what GetInfo says if your permissions are messed up.

Gale

That only verifies and repairs ***some*** system permissions. Doesn't do a thing for user owned data...

Yes - but against that, if the problem was that FFmpeg or LAME are in /usr/local and Mac is blocking read access to that location unless logged in as admin, we know from past experience that repairing permissions can fix that.

And if permissions are messed up, expected behaviour when logged in as standard user or expected behaviour when a folder has a specific permission set may not obtain any longer. Don't you agree? I have certainly had problems like that on Mac several times.

Given this other user http://forum.audacityteam.org/viewtopic ... 47&t=86457 also had a problem with coming to 2.1.1 from an audacity.cfg file last saved by 2.0.6, I will try switching from 2.0.6 to 2.1.1 some time.

If you find steps to reproduce your (Cyrano's) issues when switching between Audacity versions, please post the steps.


Gale

Gale Andrews wrote:... if the problem was that FFmpeg or LAME are in /usr/local and Mac is blocking read access to that location unless logged in as admin, we know from past experience that repairing permissions can fix that.

In my case the libraries were (and stll are) unter /Library/Application Support/audacity/

DJDemon wrote:

Gale Andrews wrote:... if the problem was that FFmpeg or LAME are in /usr/local and Mac is blocking read access to that location unless logged in as admin, we know from past experience that repairing permissions can fix that.

In my case the libraries were (and stll are) unter /Library/Application Support/audacity/

OK. That's still a system location of course, but it is from our experience much less problematic than /usr/local.

Gale

Gale Andrews wrote:

cyrano wrote:

Gale Andrews wrote:

DJDemon wrote:the "old" seettings directory did have the correct permissions

Have you done Verify Disk and Repair Permissions yet? It does not matter what GetInfo says if your permissions are messed up.

Gale

That only verifies and repairs ***some*** system permissions. Doesn't do a thing for user owned data...

Yes - but against that, if the problem was that FFmpeg or LAME are in /usr/local and Mac is blocking read access to that location unless logged in as admin, we know from past experience that repairing permissions can fix that.

It's an almost religious thing in the OSX community that fortunately doesn't do any harm. You can repair users' home folders, but only after a restart into the recovery partition. See here for a bit more:

http://osxdaily.com/2011/11/15/repair-u ... os-x-lion/

Running it from "normal" OSX, only repairs things like the kernel extension folder. I've only seen that to fix anything in 3 cases: one was a misbehaving kernel extension from a copy protection software, the other two were corporate management tools. In the last two cases, the Mac didn't even start and repairing permissions enabled a startup again - once. And that was in the period from Snow to today.

In "El Capitan", the button "repair permissions" is gone from Disk Utility.

And if permissions are messed up, expected behaviour when logged in as standard user or expected behaviour when a folder has a specific permission set may not obtain any longer. Don't you agree? I have certainly had problems like that on Mac several times.

Frankly, it's a complete mystery why it seems to solve something for some problems some of the time. I suspect flushing cashes has something to do with it. According to logic and the docs, it shouldn't do anything. But usually, users also try a restart. And I believe changing permissions AND restarting will clear some caches.

Given this other user http://forum.audacityteam.org/viewtopic ... 47&t=86457 also had a problem with coming to 2.1.1 from an audacity.cfg file last saved by 2.0.6, I will try switching from 2.0.6 to 2.1.1 some time.

If you find steps to reproduce your (Cyrano's) issues when switching between Audacity versions, please post the steps.

Remember I had the issue before, because I didn't understand I needed to delete .cfg and not simply restart Audacity?

I also had 2.0.6 on my Mac before I installed 2.1.0. And when I upgraded to 2.1.1 it didn't catch all prefs from the 2.1.0. I still have 2.1.0 installed and setting for default window behaviour (Waveform (dB) and range 0...120 dB) didn't stick until I reaffirmed and saved in both versions of Audacity.

Gale Andrews wrote: There is always a chance of corruption of some sort in audacity.cfg, where deleting that file will fix the problem. But such a problem rarely varies according to a user's permissions at the time.

The Audacity settings in my admin account were totally different from those in the user account. I suppose that I had run the old version 2.0.6 maybe once from that account, immediately after the installation, just to make sure whether the program was working.

PS:
I have attached the latest audacity.cfg that was still written by v2.0.6 and that I could find on my backup disk. Until the moment where I installed v2.1.1, only export and import paths may have been changed. Except for theses paths, this must be the cfg file that made v2.1.1 crash.

cyrano wrote:

Gale Andrews wrote:

cyrano wrote:

Gale Andrews wrote:

DJDemon wrote:the "old" seettings directory did have the correct permissions

Have you done Verify Disk and Repair Permissions yet? It does not matter what GetInfo says if your permissions are messed up.

Gale

That only verifies and repairs ***some*** system permissions. Doesn't do a thing for user owned data...

Yes - but against that, if the problem was that FFmpeg or LAME are in /usr/local and Mac is blocking read access to that location unless logged in as admin, we know from past experience that repairing permissions can fix that.

It's an almost religious thing in the OSX community that fortunately doesn't do any harm. You can repair users' home folders, but only after a restart into the recovery partition.

Again, many (not all) of the problems I have in mind are to do with LAME and FFmpeg installed to /usr/local/ - a problem that started with Lion.

cyrano wrote:See here for a bit more:
http://osxdaily.com/2011/11/15/repair-u ... os-x-lion/

Thanks for that, Cyrano.

cyrano wrote:

And if permissions are messed up, expected behaviour when logged in as standard user or expected behaviour when a folder has a specific permission set may not obtain any longer. Don't you agree? I have certainly had problems like that on Mac several times.

Frankly, it's a complete mystery why it seems to solve something for some problems some of the time. I suspect flushing cashes has something to do with it. According to logic and the docs, it shouldn't do anything. But usually, users also try a restart. And I believe changing permissions AND restarting will clear some caches.

Sometimes the Repair Permissions without restart has enabled users to read /usr/local/ again. Other times they had to go in as root to change permissions on that folder or just not use it for LAME or FFmpeg.

And yes sometimes Repair Permissions can "seemingly" fix issues with ~/Library/Application Support/audacity/ (with or without restart and without changing audacity.cfg).

I was recently able to get two instances of Audacity running on Mac from two audacity.cfg's pointing to the same temp folder - it should have been impossible, but Repair Permissions stopped the problem.

Another problem Repair Permissions fixed without reboot was Audacity apparently reading the audacity.cfg in ~/Library/Application Support/audacity/ when I had audacity.cfg in a Portable Settings folder alongside Audacity which should have been read instead.

So I don't know... but I can only speculate that system permissions issues were somehow messing up how unchanged user owned file permissions were being read. Repair Permissions is just one thing to try, and a real repair of user owned file permissions that you mentioned looks like another.

cyrano wrote:

Given this other user http://forum.audacityteam.org/viewtopic ... 47&t=86457 also had a problem with coming to 2.1.1 from an audacity.cfg file last saved by 2.0.6, I will try switching from 2.0.6 to 2.1.1 some time.

If you find steps to reproduce your (Cyrano's) issues when switching between Audacity versions, please post the steps.

Remember I had the issue before, because I didn't understand I needed to delete .cfg and not simply restart Audacity?

I also had 2.0.6 on my Mac before I installed 2.1.0. And when I upgraded to 2.1.1 it didn't catch all prefs from the 2.1.0. I still have 2.1.0 installed and setting for default window behaviour (Waveform (dB) and range 0...120 dB) didn't stick until I reaffirmed and saved in both versions of Audacity.

OK that's useful. Did you ever have Audacity 1.2? One thing I noticed in the audacity.cfg for DJDemon and the other user from 2.0.6 was that the temp folder was that which 1.2 used.


Gale

DJDemon wrote:

Gale Andrews wrote: There is always a chance of corruption of some sort in audacity.cfg, where deleting that file will fix the problem. But such a problem rarely varies according to a user's permissions at the time.

The Audacity settings in my admin account were totally different from those in the user account.

OK - until you said that I was assuming they would be the same (or nearly so) and thus the different permission level behaviour seemed more pertinent.

Thanks for the audacity.cfg file.


Gale

Gale Andrews wrote:Sometimes the Repair Permissions without restart has enabled users to read /usr/local/ again. Other times they had to go in as root to change permissions on that folder or just not use it for LAME or FFmpeg.

And yes sometimes Repair Permissions can "seemingly" fix issues with ~/Library/Application Support/audacity/ (with or without restart and without changing audacity.cfg).

I was recently able to get two instances of Audacity running on Mac from two audacity.cfg's pointing to the same temp folder - it should have been impossible, but Repair Permissions stopped the problem.

Another problem Repair Permissions fixed without reboot was Audacity apparently reading the audacity.cfg in ~/Library/Application Support/audacity/ when I had audacity.cfg in a Portable Settings folder alongside Audacity which should have been read instead.

But that sounds like an Audacity bug to me?

So I don't know... but I can only speculate that system permissions issues were somehow messing up how unchanged user owned file permissions were being read. Repair Permissions is just one thing to try, and a real repair of user owned file permissions that you mentioned looks like another.

It probably also starts a number of maintenance tasks...

It's a big, big problem that Apple either does not have docs, or hides them in the developer site. That makes a search very ineffective. And the appstore is even worse when it comes to documentation/support.

And in "EL Capitan", some permissions can't be changed by root, because OSX is rootless. You can still enable root (or switch OFF rootless, in Apple speak), but then still, you're not master of your machine. It seems root is no longer able to delete some stuff in the system area. A good thing to protect the system from noob users, but I'm waiting for malware to pick up the trick.

Oh, well, all systems seem to hide more and more stuff from the user. Are we all noobs? Or do they need to hide something from us?

Given this other user http://forum.audacityteam.org/viewtopic ... 47&t=86457 also had a problem with coming to 2.1.1 from an audacity.cfg file last saved by 2.0.6, I will try switching from 2.0.6 to 2.1.1 some time.

It seems susceptible to what settings are in the prefs, I think. I tried to retrace (and reinstall 2.0.6) but it didn't produce the same behaviour...

I also had 2.0.6 on my Mac before I installed 2.1.0. And when I upgraded to 2.1.1 it didn't catch all prefs from the 2.1.0. I still have 2.1.0 installed and setting for default window behaviour (Waveform (dB) and range 0...120 dB) didn't stick until I reaffirmed and saved in both versions of Audacity.

OK that's useful. Did you ever have Audacity 1.2? One thing I noticed in the audacity.cfg for DJDemon and the other user from 2.0.6 was that the temp folder was that which 1.2 used.[/quote]

FWIW, I never had these older Audacity versions on this Mac. I can still remember using 2.0.5, but nothing older and certainly not that far back.

i'm pretty certain I have only one .cfg on this Mac, depite having two Audacity versions. Maybe I need to make a portable install. Do you think that may yield some insight?

cyrano wrote:i'm pretty certain I have only one .cfg on this Mac, depite having two Audacity versions.

Right. Both v2.0.x and v2.1.1 are using the same path and file names to store the settings. IIRC, these were already used by v1.x.