Thomas, I've created bug [1] to discuss this issue.
[1] 341266: Lock files created on when no write operation is expected https://bugs.eclipse.org/bugs/show_bug.cgi?id=341266 cheers, ian On Mon, Mar 28, 2011 at 11:16 PM, Thomas Hallgren <[email protected]> wrote: > 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 <[email protected]> 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/.lockdue >> to can't write to read-only destination file /home/data/httpd/ >> download.eclipse.org/tools/buckminster/headless-3.7/.artifactlock/.metadata/.lockand >> 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 >> [email protected] >> https://dev.eclipse.org/mailman/listinfo/p2-dev >> > > > > -- > R. Ian Bull | EclipseSource Victoria | +1 250 477 7484 > http://eclipsesource.com | http://twitter.com/eclipsesource > > > > _______________________________________________ > p2-dev mailing list > [email protected] > https://dev.eclipse.org/mailman/listinfo/p2-dev > > -- R. Ian Bull | EclipseSource Victoria | +1 250 477 7484 http://eclipsesource.com | http://twitter.com/eclipsesource
_______________________________________________ p2-dev mailing list [email protected] https://dev.eclipse.org/mailman/listinfo/p2-dev
