Skip to main content


Eclipse Community Forums
Forum Search:

Search      Help    Register    Login    Home
Home » Eclipse Projects » EGit / JGit » JGit clone call fails because it does not hold the lock
JGit clone call fails because it does not hold the lock [message #1800178] Thu, 20 December 2018 23:31 Go to next message
Boris H is currently offline Boris HFriend
Messages: 7
Registered: December 2018
Junior Member
I have been using version 3.7.1.201504261725-r of JGit to clone repositories successfully. It was quite an old version, because it was used in an Android project that was updated to Java 8 only recently. I tried to update it to the latest version 5.2.0.201812061821-r, but since then, the clone commands seems to fail.
I get an
java.nio.file.AccessDeniedException: /data/user/0/com.myapp/files/myrepository/.git/HEAD.lock.fe153d42e64044e8b98758a805538e76 -> /data/user/0/com.myapp/files/myrepository/.git/HEAD.lock


Stacktrace is
sun.nio.fs.UnixFileSystemProvide.createLink(UnixFileSystemProvider.java:480)
java.nio.file.Files.createLink(Files.java:1086)
org.eclipse.jgit.util.FS_POSIX.createNewFileAtomic(FS_POSIX.java:455)
org.eclipse.jgit.internal.storage.file.LockFile.lock(LockFile.java:164)
org.eclipse.jgit.internal.storage.file.RefDirectoryUpdate.tryLock(RefDirectoryUpdate.java:89)
org.eclipse.jgit.lib.RefUpdate.link(Refpdate.java:708)
org.eclipse.jgit.internal.storage.file.FileRepository.create(FileRepository.java:309)
org.eclipse.jgit.api.InitCommand.call(InitCommand.java:125)
org.eclipse.jgit.api.CloneCommand.init(CloneCommand.java:274)
org.eclipse.jgit.api.CloneCommand.call(CloneCommand.java:195)


There was no local repository prior to cloning. FileRepository::create() creates all the directories needed, then in RefUpdate::link() it fails to acquire the lock with "refs/heads/master" as the target.

This is the head FileRepository object with which we call RefUpdate::link()
i.imgur.com/VKOXsne.png


Does the clone command work differently between the old version and now ?
Re: JGit clone call fails because it does not hold the lock [message #1801034 is a reply to message #1800178] Fri, 11 January 2019 12:02 Go to previous messageGo to next message
Matthias Sohn is currently offline Matthias SohnFriend
Messages: 1106
Registered: July 2009
Senior Member
On which OS and filesystem are you seeing these issues ?
Re: JGit clone call fails because it does not hold the lock [message #1801157 is a reply to message #1801034] Mon, 14 January 2019 17:14 Go to previous messageGo to next message
Boris H is currently offline Boris HFriend
Messages: 7
Registered: December 2018
Junior Member
In Android, filesystem is ext4
Re: JGit clone call fails because it does not hold the lock [message #1801329 is a reply to message #1801157] Wed, 16 January 2019 22:44 Go to previous messageGo to next message
Matthias Sohn is currently offline Matthias SohnFriend
Messages: 1106
Registered: July 2009
Senior Member
ok, I see, Android probably doesn't support hardlinks we now create to workaround issues on NFS.
Looks like we need to make this configurable. See
https://git.eclipse.org/r/#/c/112016/9/org.eclipse.jgit/src/org/eclipse/jgit/util/FS_POSIX.java
Re: JGit clone call fails because it does not hold the lock [message #1801925 is a reply to message #1801329] Tue, 29 January 2019 14:50 Go to previous messageGo to next message
Boris H is currently offline Boris HFriend
Messages: 7
Registered: December 2018
Junior Member
Thank you, I've tried updating jgit to 4.4.1.201607150455-r which is one of the latest versions that doesn't incorporate that NFS fix.
Unfortunately I now get a
Fatal Exception: java.lang.NoSuchMethodError
No virtual method toPath()Ljava/nio/file/Path; in class Ljava/io/File; or its super classes (declaration of 'java.io.File' appears in /system/framework/core-oj.jar)
org.eclipse.jgit.util.FileUtils.exists (FileUtils.java:582)
org.eclipse.jgit.util.FS.exists (FS.java:685)
org.eclipse.jgit.internal.storage.file.ObjectDirectory.exists (ObjectDirectory.java:194)
org.eclipse.jgit.internal.storage.file.FileRepository.<init> (FileRepository.java:227)
org.eclipse.jgit.lib.BaseRepositoryBuilder.build (BaseRepositoryBuilder.java:580)
org.eclipse.jgit.api.Git.open (Git.java:117)
org.eclipse.jgit.api.Git.open (Git.java:99)

because the Files java classes that jgit uses starting from version 4.0 have only become available in Android starting from API version 26, so it will crash with devices below Android 8.0.
Is there an alternative solution? Otherwise for the time being I will revert back to version 3.7.1.201504261725-r
Re: JGit clone call fails because it does not hold the lock [message #1801954 is a reply to message #1801925] Tue, 29 January 2019 21:19 Go to previous messageGo to next message
Thomas Wolf is currently offline Thomas WolfFriend
Messages: 175
Registered: August 2016
Senior Member
Now that's strange because 5.2.0 certainly also uses File.toPath(), so you should have gotten that error also with 5.2.0.

For the original AccessDeniedException, see bug 543956.
Re: JGit clone call fails because it does not hold the lock [message #1802112 is a reply to message #1801954] Fri, 01 February 2019 11:25 Go to previous messageGo to next message
Boris H is currently offline Boris HFriend
Messages: 7
Registered: December 2018
Junior Member
Yes I guess 5.2 would have both the Files error and the NFS related error on Android devices.
4.4 only has the Files error.
3.7 is the current version that I have and that works.
I initially wanted to update jgit to a more recent version that includes the fix for the Turkish i bug, but this fix is only present starting from 4.7. Otherwise if it's not possible to do anything I can always fork 3.7 and manually add Locale.ROOT where needed to fix the Turkish i bug.
Re: JGit clone call fails because it does not hold the lock [message #1802287 is a reply to message #1802112] Wed, 06 February 2019 01:38 Go to previous messageGo to next message
Matthias Sohn is currently offline Matthias SohnFriend
Messages: 1106
Registered: July 2009
Senior Member
This was fixed recently on the master branch [1]. You can update to the nightly build [2].

[1] https://git.eclipse.org/r/#/c/135973/
[2] https://download.eclipse.org/egit/updates-nightly
Re: JGit clone call fails because it does not hold the lock [message #1802548 is a reply to message #1802287] Mon, 11 February 2019 18:13 Go to previous messageGo to next message
Boris H is currently offline Boris HFriend
Messages: 7
Registered: December 2018
Junior Member
I've tried with the latest version from the nightly build, but I get the following error :
java.lang.NoSuchMethodError: No virtual method keySet()Ljava/util/concurrent/ConcurrentHashMap$KeySetView; 
in class Ljava/util/concurrent/ConcurrentHashMap; or its super classes 
(declaration of 'java.util.concurrent.ConcurrentHashMap' appears in /system/framework/core-oj.jar)
at org.eclipse.jgit.attributes.FilterCommandRegistry.getRegisteredFilterCommands(FilterCommandRegistry.java:118)

This is because in java 8 keySet() returns a ConcurrentHashMap.KeySetView but the Android code returns a Set
    // Android-changed: Return type for backwards compat. Was KeySetView<K,V>. http://b/28099367
    public Set<K> keySet() {
        KeySetView<K,V> ks;
        return (ks = keySet) != null ? ks : (keySet = new KeySetView<K,V>(this, null));
    }


Following this Stack Overflow answer, changing in FilterCommandRegistry
private static ConcurrentHashMap<String, FilterCommandFactory> filterCommandRegistry = new ConcurrentHashMap()

to
private static Map<String, FilterCommandFactory> filterCommandRegistry = new ConcurrentHashMap()

fixes the problem
Re: JGit clone call fails because it does not hold the lock [message #1802549 is a reply to message #1802548] Mon, 11 February 2019 18:31 Go to previous messageGo to next message
Boris H is currently offline Boris HFriend
Messages: 7
Registered: December 2018
Junior Member
Thank you for being so responsive in providing a fix for the NFS bug! Does this also fix the problem of java.nio.file.Path not being available on Android devices below 8.0 / API level 26 ?
https://stackoverflow.com/questions/32873216/jgit-error-caused-by-java-lang-nosuchmethoderror-no-virtual-method-topath

[Updated on: Mon, 11 February 2019 19:01]

Report message to a moderator

Re: JGit clone call fails because it does not hold the lock [message #1802736 is a reply to message #1802549] Thu, 14 February 2019 21:36 Go to previous messageGo to next message
Thomas Wolf is currently offline Thomas WolfFriend
Messages: 175
Registered: August 2016
Senior Member
No, of course not. JGit uses nio classes, and if your target doesn't have them, you'll have to use an older version of JGit that didn't use nio yet, as pointed out in the StackOverflow thread you linked.
Re: JGit clone call fails because it does not hold the lock [message #1802966 is a reply to message #1802736] Tue, 19 February 2019 20:36 Go to previous messageGo to next message
Matthias Sohn is currently offline Matthias SohnFriend
Messages: 1106
Registered: July 2009
Senior Member
The readme clearly states that current JGit needs at least Java 8
https://git.eclipse.org/r/plugins/gitiles/jgit/jgit/+/refs/heads/master/README.md#Warnings_Caveats
Re: JGit clone call fails because it does not hold the lock [message #1803007 is a reply to message #1802736] Wed, 20 February 2019 16:53 Go to previous message
Boris H is currently offline Boris HFriend
Messages: 7
Registered: December 2018
Junior Member
Great thank you, I will revert back to 3.7 and add the Turkish i fix !
Our project is using Java 8, but Android has a tweaked version of ConcurrentHashMap in order to be backward compatible.

[Updated on: Thu, 21 February 2019 16:12]

Report message to a moderator

Previous Topic:Eclipse JGit
Next Topic:Frontend Data with EGit
Goto Forum:
  


Current Time: Sat Dec 14 11:15:19 GMT 2019

Powered by FUDForum. Page generated in 0.03003 seconds
.:: Contact :: Home ::.

Powered by: FUDforum 3.0.2.
Copyright ©2001-2010 FUDforum Bulletin Board Software

Back to the top