[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [p2-dev] Unwanted side effects from locking

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.  

We do unlock afterwards, but this doesn't appear to actually delete the file (we just give up the lock on it). 

 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)?


On Sun, Mar 27, 2011 at 5:02 AM, Thomas Hallgren <thomas@xxxxxxx> wrote:

I installed a product from our repository on build.eclipse.org using the director. I used a 'file:/' URL as a -r argument. This resulted in a .artifactlock/.metadata in that repository that was owned by me and only writable by me and my group. This lead to problems later on when our Hudson build attempted to publish a new repository to the same location. Message as follows:

Failed to copy /opt/users/hudsonbuild/.hudson/jobs/buckminster-head/workspace/output/org.eclipse.buckminster.site.eclipse.headless_1.4.0-eclipse.feature/site.p2/.artifactlock/.metadata/.lock to /home/data/httpd/download.eclipse.org/tools/buckminster/headless-3.7/.artifactlock/.metadata/.lock due to can't write to read-only destination file /home/data/httpd/download.eclipse.org/tools/buckminster/headless-3.7/.artifactlock/.metadata/.lock and I couldn't delete the corrupt /home/data/httpd/download.eclipse.org/tools/buckminster/headless-3.7/.artifactlock/.metadata/.lock

Does this mean that the semantics for a read-only access to the repository is different when I use 'file' or 'http'? I imagine it will be hard to set a lock using the latter. Why isn't the lock (and the directories that it creates), writable to everyone? I think that they either should be "owned" by the publisher and thus only placed there when publishing or be fully accessible to everyone.

- thomas

p2-dev mailing list

R. Ian Bull | EclipseSource Victoria | +1 250 477 7484
http://eclipsesource.com | http://twitter.com/eclipsesource