On my Mac (10.8.3) this little script:
gradle --info -q upper
task upper << {
String someString = 'mY_nAmE'
println "Original: " + someString
println "Upper case: " + someString.toUpperCase()
}
produces:
FAILURE: Build failed with an exception.
- What went wrong: Could not open task artifact state cache (/Volumes/programming/DevJava/WebApp.Base/.gradle/1.7-20130529220026+0000/taskArtifacts). > java.io.IOException: Operation not supported
(The same result with 1.6)
This works: gradle --project-cache-dir /tmp -q upper
My project sits on a network drive (samba share) All the rights are properly set.
I also encountered this problem today.
The directory was mounted with command
mount_smbfs -f 0664 -d 0775 //zouguangxian@host/x$ ~/Volumes/X
In the project directory, execute “gradle tasks” will failed with “java.io.IOException: Operation not supported”
[zouguangxian@]$ gradle tasks
[zouguangxian@]$ ls -la .gradle/1.6/taskArtifacts
total 64
drwxrwxr-x
1 zouguangxian
staff
16384
6
1 21:53 .
drwxrwxr-x
1 zouguangxian
staff
16384
6
1 21:53 ..
-rw-rw-r--
1 zouguangxian
staff
0
6
1 21:53 cache.properties.lock
But if I execute “gradle --project-cache-dir /tmp tasks” like you suggests, it will succeed.
[zouguangxian@]$ gradle --project-cache-dir /tmp tasks
[zouguangxian@]$ ls -la /tmp/1.6/taskArtifacts/
total 96
drwxr-xr-x
6 zouguangxian
wheel
204
6
1 21:08 .
drwxr-xr-x
3 zouguangxian
wheel
102
6
1 21:08 ..
-rw-r--r--
1 zouguangxian
wheel
30
6
1 21:08 cache.properties
-rw-r--r--
1 zouguangxian
wheel
2
6
1 21:08 cache.properties.lock
-rw-r--r--
1 zouguangxian
wheel
19346
6
1 21:08 fileSnapshots.bin
-rw-r--r--
1 zouguangxian
wheel
19373
6
1 21:08 taskArtifacts.bin
By comparing the permissions of the file generatd by these commands, I found that gradle create files as :wheel group instead of :staff group.
The operation system is Mac OS Mountain Lion 10.8.3.
[zouguangxian@]$ uname -a
Darwin ZoutekiMacBook-Pro.local 12.3.0 Darwin Kernel Version 12.3.0: Sun Jan
6 22:37:10 PST 2013; root:xnu-2050.22.13~1/RELEASE_X86_64 x86_64
So looks that if gradle team change :wheel group to :staff group when the tool generate files will resolve this problem.
Which group files written by Gradle belong to isn’t controlled by Gradle, but by your OS/filesystem. Typically, the group is inherited from the parent directory.
[zouguangxian@]$ ls -ls ~/Volumes/ | grep X
0 drwxr-xr-x
2 zouguangxian
staff
68
4
9 23:33 X
[zouguangxian@]$ mount_smbfs -f 0664 -d 0775 //zouguangxian@host/x$ ~/Volumes/X
[zouguangxian@]$ ls -ls ~/Volumes/ | grep X
32 drwxrwxr-x
1 zouguangxian
staff
16384 12 31
1979 X
[zouguangxian@]$ groups zouguangxian
staff everyone _appstore localaccounts _appserverusr admin _appserveradm _lpadmin _lpoperator _developer access_bpf com.apple.access_screensharing-disabled
It looks like I’m not a member of wheel group and ‘wheel’ is not inherited from parent directory.
As http://en.wikipedia.org/wiki/Wheel_(Unix_term) described: > Modern Unix systems use user groups to control access privileges. The wheel group is a special user group used on some Unix systems to control access to the su command, which allows a user to masquerade as another user (usually the super user).
Yes, the group is inherited from the parent directory.
If I set project-cache-dir to ~/tmp, the following command will succeed to execute.
[zouguangxian@]$ ls -la ~| grep tmp
drwxr-xr-x
3 zouguangxian
staff
102
6
1 23:35 tmp
[zouguangxian@]$ gradle --project-cache-dir ~/tmp tasks
[zouguangxian@]$ ls -la ~/tmp/1.6/taskArtifacts/
total 96
drwxr-xr-x
6 zouguangxian
staff
204
6
1 23:35 .
drwxr-xr-x
3 zouguangxian
staff
102
6
1 23:35 ..
-rw-r--r--
1 zouguangxian
staff
30
6
1 23:35 cache.properties
-rw-r--r--
1 zouguangxian
staff
2
6
1 23:35 cache.properties.lock
-rw-r--r--
1 zouguangxian
staff
19346
6
1 23:35 fileSnapshots.bin
-rw-r--r--
1 zouguangxian
staff
19373
6
1 23:35 taskArtifacts.bin
Is it a bug of mount_smbfs cause “java.io.IOException: Operation not supported” ?
I am sure it’s not a Samba-bug. Reading and writing to all subdirectories works. In my case /Volumes/programming/DevJava/… is my DevVolume - all other projects are on that volume - never had a problem before with reading/writing files. I am using Java 6 - could this cause the problem? (I can’t switch to J7 at - the moment so I can’t test)
It may not be a Samba bug, but it’s likely Samba (setup) related. Also check execute rights (for listing directories) and try without Gradle daemon (’–no-daemon’). To Gradle/Java, it’s just another file system, hence I consider it unlikely that anything can or needs to be changed there. I’d be surprised if a different JRE helped, but it’s worth a shot.
I haven’t used Samba in a while, but I’d be hesitant to use it for builds, because disk performance tends to have a huge impact on build times.