File locking fails on ExFAT SD card #4329
Comments
|
Did you share this Gradle user home across a network share? |
|
@oehme I did not share this over network. It's on my local machine.
|
|
Could you try to kill all existing gradle daemons and retry? You can kill gradle daemon processes by one of the following:
|
|
@blindpirate I also tried it several times. I ran following command: Still getting same error. No luck there either One point I would like to note here is that I am using an SD card as my secondary storage in macbook. I don't know if this has anything to do with the issue. |
|
@lankesh87 Try delete |
|
@blindpirate Yup did that too. Deleted Still no luck :( |
|
|
@oehme Haven't tried that yet. I'll try straightaway and let you know. Give me 10 min :) |
|
I do not have any |
|
So building project on mac's primary storage worked. Seems like gradle is having issues with secondary storage like SD cards. |
|
What file system do you use on that SD card? It might not fully support file locking. |
|
The file system on SD Card is ExFAT USB Internal Physical Volume • ExFAT |
|
The card may be write-protected or ExFAT may not support file locking. In any case our error message should be much clearer here. |
|
Can you guide me to generate logs for this particular action. Cause I could write to the SD Card via File Explorer |
This is the current info of SD Card:Permissions |
|
@lankesh87 Attaching the |
oehme
changed the title
Command Run
CLI OutputDebug LogsAttaching logs generated by |
|
Do let me know what the issue was if at all there is one I am curious :) |
|
Seems very much like the file system doesn't support locking. You might want to experiment with different file systems for your SD card, e.g. try out |
|
@oehme Unfortunately I cannot format my current drive. |
|
@oehme I also have external SSD with ExFAT. And my gradle cache directory pointed to this external SSD: I have the same error, same console output as @lankesh87 has. Thank you. |
|
same issue on 4.10.2 |
|
I did have the same issue with
Finally, as I said, I got rid of that issue with one or combinations of all those attempts I made. However, I still get one another error/warning during the project creation at times(not a blocking issue, though)
Hope it helps. |
|
same issue on 4.6 && 5.0 ,macos 10.13.6, usb 3.0 external hdd with exfat
Gradle 5.0Build time: 2018-11-26 11:48:43 UTC Kotlin DSL: 1.0.4 |
|
same issue macos 10.14.3, gradle 4.10.2, external SSD exFat. |
|
same here with MacOS 10.14.6, java 1.8.0_202-release, with source code on ExFat partition on a directly connected Drobo. partition is less than 10% used. moved the code over to a HFS+ partition and ran like a charm. |
|
yes ,the system file exfat don't support. |
|
Is there any other ways to solve this issue? I want to share my files between windows and mac os, so exfat is the best format for me. |
|
I also have this problem with my project files on a ext4 partition, which I access using Paragon LinuxFS. If Gradle can't properly create lock files, it should either not use them and synchronize in some other way (maybe loopback network connections) or automatically store them in another location (for example somewhere in the home directory). |
|
I had this situation in two machines MacOS and Windows due the following: I used for each laptop a pendrive it with the purpose to save space in the main hard disk about the repository content (the same case applies for an external HDD/SSD connected how a secondary drive). Scenario Exits a Secondary Drive that is used how repository for Gradle Solution Format the secondary device with the same format type as the main hard disk has and problem solved!. I am not sure why this situation or behavior. Otherwise an error message about a Remember I had this situation in 2 PC and the format types for each OS is different. I think it should be documented in Gradle documentation. I am going to create an issue for this. |
Hello @oehme - I did realize that for network it is locked. Is there an official documentation to solve this? Thanks in advance |
ljacomet
added
in:invoking-gradle
|
Is there any new solution to this situation without having to reformat the Ext HD to match the primary? |
|
I've also been experiencing this with an exFAT SSD for months, more details can be found at the closed issue above Is there any hope for a fix such as an alternative to file locking or something similar? |
me too |
+1 |
|
I was able to build on exFAT using Android Studio gradle plugin version 7.0.0, but for some reason older and newer versions did not work (did not spend time investigating why). Putting this here in case it can be useful for someone. |
|
D*mn it takes me 2 days to come to this thread. I have .gradle folder on external usb exfat driver, shared between Windows and Mac. While the former works, the latter fails on locking, bla, bla,.. what was even misleading is VPN alike log, 'I don't know which port to listen to'. |
|
Same exact issue here, same stacktrace. It works when gradle home is on an APFS drive but not on exFAT. |
|
I may be wrong about this, but I think exFAT is unsupported due to file locking being unsupported. But since the cache doesn't use file locking (as far as I know), maybe a configuration option can be added to change only the cache directory. |
|
I have had the issue throwing an error on |
|
Hi all, passed through this issue while working on something with similar symptoms. This is quite possibly JDK-8205404. |
|
With this format I can do it normally |
and others
Expected Behavior
Current Behavior
Context
I installed gradle using brew. Then I tried running gradle command in my project directory:
$>gradleBut it resulted in above error exactly after 1 minute.
I also stopped gradle daemon using:
$>gradle --stopIt says daemon stopped. But I still get the error.
My project directory has following structure:
Steps to Reproduce (for bugs)
Upgrade Macbook Pro to macOS HighSierra (10.13.3).
Freshly install gradle. Create project with two java files in
./src/main/java/hello.Then run gradle command
$>gradleYour Environment
Java:
Gradle:
MacOS:
Stack Trace:
The text was updated successfully, but these errors were encountered: