Re: [p2-dev] Unwanted side effects from locking

[Thomas Hallgren <thomas@xxxxxxx>]

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,

ian

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

Hi,

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
p2-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/p2-dev

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