Audacity Forum

only the user data ("~/username" to clarify), like the Audacity preferences, is stored and accessed through the network

Without getting down to the fine details, Audacity doesn't understand network delays and management (yet). If it needs to access any part of the application over the network then that portion becomes subject to critical timing. It's possible you got lucky with the other version.

Koz

TwinOak wrote:Leland, I will check this out after the Easter holidays, but I have no memory at all seeing an .audacity.sock file in "application support/audacity" on my regular (working) mobile account, which is configured to show hidden files.
A quick google shows no sign that SL-Server wouldn't support sock files. My knowledge about them is very limited though, this is the first time I'm made aware that they exist.

You would search for Unix domain sockets. They are for IPC between processes running on the same machine. I'll also poke around to see if I can get a definitive answer.

Enjoy the holiday.

Leland

TwinOak wrote:Leland, I will check this out after the Easter holidays, but I have no memory at all seeing an .audacity.sock file in "application support/audacity" on my regular (working) mobile account, which is configured to show hidden files.
A quick google shows no sign that SL-Server wouldn't support sock files. My knowledge about them is very limited though, this is the first time I'm made aware that they exist.

I couldn't find a definitive answer, so I tested it myself. While I don't have OSX Server, what I try to pass off for a brain kicked in and I realized that I can do AFP sharing between two clients...DOH!

Anyway, as suspected, it is failing when attempting to create the socket. Which, after thinking about it, makes sense because Unix domain sockets are meant to be used within a single host.

I don't see a workaround for you unless you want me to build you a private version that relocated the socket file to the users "temp" directory. I assume that would be on the local filesystem???

Leland

Thanks for looking into this, Leland.

Leland wrote:as suspected, it is failing when attempting to create the socket. Which, after thinking about it, makes sense because Unix domain sockets are meant to be used within a single host.

I don't see a workaround for you unless you want me to build you a private version that relocated the socket file to the users "temp" directory.

As I understood it, the original plan was to put the socket file in the user's temp directory http://bugzilla.audacityteam.org/show_b ... id=202#c13 . Did we change that because we're planning to move the lock file into Audacity's configuration directory?

Gale

Gale Andrews wrote:Thanks for looking into this, Leland.

Leland wrote:as suspected, it is failing when attempting to create the socket. Which, after thinking about it, makes sense because Unix domain sockets are meant to be used within a single host.

I don't see a workaround for you unless you want me to build you a private version that relocated the socket file to the users "temp" directory.

As I understood it, the original plan was to put the socket file in the user's temp directory http://bugzilla.audacityteam.org/show_b ... id=202#c13 . Did we change that because we're planning to move the lock file into Audacity's configuration directory?

Gale

At the time, the only reason for doing so was so that it would be as easily usable by other users. The Audacity data directory did the same thing, but we now know that there's a more concrete reason to put the socket file in the user specific temp directory.

Leland

Leland wrote:

Gale Andrews wrote:Thanks for looking into this, Leland.

Leland wrote:as suspected, it is failing when attempting to create the socket. Which, after thinking about it, makes sense because Unix domain sockets are meant to be used within a single host.

I don't see a workaround for you unless you want me to build you a private version that relocated the socket file to the users "temp" directory.

As I understood it, the original plan was to put the socket file in the user's temp directory http://bugzilla.audacityteam.org/show_b ... id=202#c13 . Did we change that because we're planning to move the lock file into Audacity's configuration directory?

Gale

At the time, the only reason for doing so was so that it would be as easily usable by other users. The Audacity data directory did the same thing, but we now know that there's a more concrete reason to put the socket file in the user specific temp directory.

Leland

So if we don't need the socket file to be in the same directory as the lock file, it seems we should actually go back to putting the socket file in the user specific temp directory.

I "think" TwinOak is saying that the chosen Audacity temp folder is actually on the local computer and not being read over the network. But if it was chosen to put the Audacity temp folder where the ~/username is (on the network, as I understand it) then it would presumably still fail.


Gale

Gale Andrews wrote:

Leland wrote:

Gale Andrews wrote:Thanks for looking into this, Leland.

Leland wrote:as suspected, it is failing when attempting to create the socket. Which, after thinking about it, makes sense because Unix domain sockets are meant to be used within a single host.

I don't see a workaround for you unless you want me to build you a private version that relocated the socket file to the users "temp" directory.

As I understood it, the original plan was to put the socket file in the user's temp directory http://bugzilla.audacityteam.org/show_b ... id=202#c13 . Did we change that because we're planning to move the lock file into Audacity's configuration directory?

Gale

At the time, the only reason for doing so was so that it would be as easily usable by other users. The Audacity data directory did the same thing, but we now know that there's a more concrete reason to put the socket file in the user specific temp directory.

Leland

So if we don't need the socket file to be in the same directory as the lock file, it seems we should actually go back to putting the socket file in the user specific temp directory.

Yepper, that's my take on it as well.

Leland

Gale Andrews wrote:I "think" TwinOak is saying that the chosen Audacity temp folder is actually on the local computer and not being read over the network. But if it was chosen to put the Audacity temp folder where the ~/username is (on the network, as I understand it) then it would presumably still fail.

Gale Andrews wrote:

Leland wrote:

Gale Andrews wrote:Thanks for looking into this, Leland.

Leland wrote:as suspected, it is failing when attempting to create the socket. Which, after thinking about it, makes sense because Unix domain sockets are meant to be used within a single host.

I don't see a workaround for you unless you want me to build you a private version that relocated the socket file to the users "temp" directory.

As I understood it, the original plan was to put the socket file in the user's temp directory http://bugzilla.audacityteam.org/show_b ... id=202#c13 . Did we change that because we're planning to move the lock file into Audacity's configuration directory?

Gale

At the time, the only reason for doing so was so that it would be as easily usable by other users. The Audacity data directory did the same thing, but we now know that there's a more concrete reason to put the socket file in the user specific temp directory.

Leland

So if we don't need the socket file to be in the same directory as the lock file, it seems we should actually go back to putting the socket file in the user specific temp directory.

I "think" TwinOak is saying that the chosen Audacity temp folder is actually on the local computer and not being read over the network. But if it was chosen to put the Audacity temp folder where the ~/username is (on the network, as I understand it) then it would presumably still fail.


Gale

To answer the question and clarify: we do not change the setting for the temp folder so it gets created in the default location on the local drive in all scenarios above.

I'm very impressed and grateful that you're taking the time, thanks a bunch!
Alexander

Leland has moved the socket file to the temp dir https://github.com/audacity/audacity/commit/44900e1.

If you want to try it, it should be in the latest nightly build from the top of http://www.audacity.homerow.net/index.p ... order=desc.


Gale

Nice! Can hopefully test this tomorrow, thanks!

/A