On 2018-4-6 02:26 , Bjarne D Mathiesen wrote:
> When running port in certain situations under the root account, it fails
>
> In particular, I've got at script
>
> diffPorts :
> #!/macports/bin/bash
> diff <( port -q search ${1} ) \
> <( port -q installed name:^${1} | awk '{print $1}' ) \
> | grep '<'
>
> which I'm using to get a list of sub-ports not installed;
> eg : ./diffPorts php72-
>
> When running './diffPorts php72-' as root I get this :
>
> Error: /macports/bin/port: Failed to initialize MacPorts, error deleting
> "/macports/var/macports/home/Library/Preferences/com.apple.dt.Xcode.plist":
> no such file or directory
> < error deleting
> "/macports/var/macports/home/Library/Preferences/com.apple.dt.Xcode.plist":
> no such file or directory
> < while executing
> < "file delete -force "${target_dir}/com.apple.dt.Xcode.plist""
> < (procedure "macports::copy_xcode_plist" line 5)
> < invoked from within
> < "macports::copy_xcode_plist $env(HOME)"
> < (procedure "mportinit" line 540)
> < invoked from within
> < "mportinit ui_options global_options global_variations"
>
> each sub-part of the script works perfectly; that is
> port -q search php72-
> port -q installed name:^php72- | awk '{print $1}'
> have no issues; but when combining them in the redirection for 'diff' I
> get the error; but only when the script is being run under the root
> account. When running it under an admin or normal user account, there
> are no issues.
My guess is that this is a bug in Tcl's file command. Deleting a
nonexistent file is not supposed to be considered an error. But by
starting two instances of port(1) at the same time, a race condition
arises. The 'file delete' command probably checks whether the file
exists, returns TCL_OK if not, and then attempts to delete the file. If
the file has been deleted by the other running instance (or indeed
anything else) between these two steps, then the actual deletion fails,
and it incorrectly returns an error.
You don't see the problem when running as another user because we only
copy the Xcode plist when running as root. I guess the good news is that
there's little reason to be running this command as root?
- Josh
