Community
Participate
Working Groups
I've been looking at the console logs lately from the test suite runs, and I've seen a lot of these messages: [Fatal Error] :1:1: Premature end of file. I'm trying to track down where this is coming from. I think it might be related to some code in the SimpleArtifactRepository. Specifically here is some of the stack: SimpleArtifactRepositoryIO$Parser.parse(InputStream) line: 310 SimpleArtifactRepositoryIO.read(URI, InputStream, IProgressMonitor, boolean) line: 101 SimpleArtifactRepositoryFactory.load(URI, int, IProgressMonitor, boolean) line: 107 SimpleArtifactRepository.doLoad(IProgressMonitor) line: 1442 SimpleArtifactRepository.load(IProgressMonitor) line: 1399 SimpleArtifactRepository.getRules() line: 905 SimpleArtifactRepositoryIO$Writer.write(SimpleArtifactRepository) line: 231 SimpleArtifactRepositoryIO.write(SimpleArtifactRepository, OutputStream) line: 64 SimpleArtifactRepository.save(boolean) line: 1148 SimpleArtifactRepository.save() line: 1115 SimpleArtifactRepository.doSetProperty(String, String, IProgressMonitor, boolean) line: 1177 SimpleArtifactRepository.setProperty(String, String, IProgressMonitor) line: 1189 SimpleArtifactRepository(AbstractRepository).setProperty(String, String) line: 190 I think this is a new repository being created. The file on disk is 0 length which makes sense, we've opened a stream and started writing to it but then we try and read the mapping rules from disk and can't. This is the suspicious code in #getRules(): public synchronized String[][] getRules() { if (!holdsLock() && URIUtil.isFileURI(getLocation())) { load(new NullProgressMonitor()); } return mappingRules; } I believe we should have some protection there to know whether or not we are in the middle of a "write" operation or if we don't believe the repo should exist.
Thanks DJ. I was looking at this yesterday, trying to figure out if this was a new problem. I'll take this one.
(In reply to comment #0) > > public synchronized String[][] getRules() { > if (!holdsLock() && URIUtil.isFileURI(getLocation())) { > load(new NullProgressMonitor()); > } > return mappingRules; > } > > I believe we should have some protection there to know whether or not we are in > the middle of a "write" operation or if we don't believe the repo should exist. the !holdsLock() is supposed to protect against this. That is, if we are currently writing we should have the lock and not re-load the rules. I did some digging, and appears that we think this area is 'read-only', so we never acquire a lock (we cannot lock a read only area). Obviously the area is not read-only (or we would not be saving). I need to review the logic for checking if an area is read-only.
When a file does not exist, calling file#canWrite returns false. However, this doesn't mean the area is readOnly. To properly check, I need to traverse to the parent and see if we can write there (and continue this recursively until we find a file / directory that exists and use that to determine if it's writeable). I'm putting a fix together and running the tests now.
Created attachment 192308 [details] Patch v1 This moves up the parent chain to determine if location is really going to be 'read-only'. Note, this is only for new repos, if a repo already exists, then we simple check if we can write to it.
Created attachment 192309 [details] mylyn/context/zip
Fixed in head. Thanks again DJ.
(In reply to comment #6) > Fixed in head. Thanks again DJ. I wanted to double check if this fix will correct the behavior I am seeing with 3.7M6a. 1. If eclipse tries to resolve a target definition pointing to a P2 repo that is read only, it fails because it can't create the .lock file. 2. Why is eclipse trying to lock a P2 repo on a read, shouldn't this only happen with a write? 3. If I run as a user that has write privs to the P2 repo, the target definition resolution works fine, but creates a lock file. That lock file never goes away even after exiting eclipse causing it to remain locked forever.
This problem was related to trying to create a repository, and our implementation assuming that the area was read-only (when it wasn't). It may fix your issue, but I've opened bug 341648 to double check. As for your other concerns: 2. This is tricky. We need to be mindful that two separate processes may be reading / writing the same location at the same time. In this case, you don't want the artifacts.xml to disappear as your trying to read it. Having said that, we may have to forgo the read locks as they are causing problems and we don't see any other viable solution. This is being tracked in bug 341266. 3. This is how OSGi locking works. The file remains, although it doesn't mean that the file is 'locked' (you've relinquished the lock on the file). Same thing happens in your workspace/.metadata directory (after you exit eclipse, you have a .lock file). We may want to look at the file permissions we set on the file, to make it easier to remove (set it to rw-rw-rw- for example).
*** Bug 339862 has been marked as a duplicate of this bug. ***
