Date 7.5.2014 10:49, Julian Scheel wrote:
Am 07.05.2014 09:19, schrieb Takashi Iwai:
At Tue, 6 May 2014 21:32:19 +0200, Julian Scheel wrote:
It can not be generally assumed that the directories in which asound.state resides are writable. Instead using /tmp as location for lock files seems more reliable.
The subject and changelog don't match with the actual change. Now it's /var/log instead of /tmp, right?
Sorry for that. Must have been too late.
I also didn't note that. I applied your v2 patch to the git repo - I forced update now.
Besides that, it'd be better to allow a full path name for a lock file instead of a directory name. If you give a different file name via -f option, you have a high chance to conflict with the existing file in /var/lock.
So, you'd prefer a --lock-file/-L option which can be used to set an explicit lock file?
I changed '-D' to '-O' option (file) and used '-L' option to select the "no-lock" behaviour for the global configuration file. Note that the locking is default only for the global file, other files are not lock protected.
http://git.alsa-project.org/?p=alsa-utils.git;a=commitdiff;h=158a67f6f5058be...
Furthermore, for solving *your* problem (restoring from read-only rootfs), an easier option would be allowing to restore the system default without locking.
While this is true I think making the locking mechanism more robust is a good thing anyway.
Yup.
Jaroslav