Hi Ian,
On 2011-03-28 23:20, Ian Bull wrote:
Hi Thomas,
The locking is done whenever a 'writable' artifact repository
is accessed. In the case of HTTP, the artifact is not considered
'writable'. However, when you use a file:/ URL, a lock may be
acquired. I say 'may' because we only lock on 'write'
operations. However, we check for a lock on read operations
(this may create the .lock file), and IIRC, we lock when we
first load the repository.
A repository that is passed to the director using the -r option
should not be altered IMO. It should be considered read-only and it
shouldn't matter which protocol that is used in the URL. If you need
lock protected reads then the whole concept of "dumb server" is
wrong. A client cannot place a lock in most 'read' situations and
placing it only when using 'file' protocol is just confusing and
will lead to problems that might be hard to analyze (like this one).
We do unlock afterwards, but this doesn't appear to actually
delete the file (we just give up the lock on it).
I think that even if the file is deleted, that will not help in this
case since the directory that is also created doesn't allow write
access to everyone.
In your particular case, how do you create a lock at this
location? Does your user have write access here (do they 'own'
the artifacts.xml file too)?
The first lock was apparently created by the director when I passed
the repository to it as a -r option. The lock was then writable by
me and my group. It was not writable by the original publisher
(hudsonbuild) and that caused the subsequent failure to replace the
file.
- thomas
cheers,
|