I was curious and ran the tests for the filesystem storage provider
2.0.0-SNAPSHOT.
Indeed there are many tests skipped. If I look into the target dir, only
.\target\basedir\fun-blobstore-test\ss
exists after the tests have failed.
fun-blobstore-test and ss have the same strange permissions as I
mentioned in my earlier post.
I guess that's the reason why they're failing.
Tests run: 225, Failures: 3, Errors: 0, Skipped: 215, Time elapsed:
22.794 sec <<< FAILURE! - in TestSuite
testBlobExists(org.jclouds.filesystem.FilesystemBlobStoreTest) Time
elapsed: 0.145 sec <<< FAILURE!
java.io.IOException: Unable to create parent directories of
.\target\basedir\fun-blobstore-test\ss\asdas\0f50457a-21ec-4d0f-aeb9-0277e152d131.jpg
at com.google.common.io.Files.createParentDirs(Files.java:645)
at
org.jclouds.filesystem.utils.TestUtils.createBlobAsFile(TestUtils.java:194)
at
org.jclouds.filesystem.FilesystemBlobStoreTest.testBlobExists(FilesystemBlobStoreTest.java:602)
tearDown(org.jclouds.filesystem.FilesystemBlobStoreTest) Time elapsed:
10.081 sec <<< FAILURE!
java.io.IOException: Could not delete:
.\target\basedir\fun-blobstore-test\ss
at org.jclouds.filesystem.util.Utils.delete(Utils.java:101)
at
org.jclouds.filesystem.util.Utils.deleteRecursively(Utils.java:76)
at
org.jclouds.filesystem.util.Utils.deleteRecursively(Utils.java:71)
at
org.jclouds.filesystem.util.Utils.deleteRecursively(Utils.java:71)
at
org.jclouds.filesystem.FilesystemBlobStoreTest.tearDown(FilesystemBlobStoreTest.java:105)
setUp(org.jclouds.filesystem.strategy.internal.FilesystemStorageStrategyImplTest)
Time elapsed: 9.742 sec <<< FAILURE!
java.io.IOException: Could not delete:
.\target\basedir\fun-blobstore-test\ss
at org.jclouds.filesystem.util.Utils.delete(Utils.java:101)
at
org.jclouds.filesystem.util.Utils.deleteRecursively(Utils.java:76)
at
org.jclouds.filesystem.util.Utils.deleteRecursively(Utils.java:71)
at
org.jclouds.filesystem.utils.TestUtils.cleanDirectoryContent(TestUtils.java:175)
at
org.jclouds.filesystem.strategy.internal.FilesystemStorageStrategyImplTest.setUp(FilesystemStorageStrategyImplTest.java:97)
Results :
Failed tests:
FilesystemBlobStoreTest.testBlobExists:602 » IO Unable to create
parent direct...
FilesystemBlobStoreTest.tearDown:105 » IO Could not delete:
.\target\basedir\f...
FilesystemStorageStrategyImplTest.setUp:97 » IO Could not delete:
.\target\bas...
Tests run: 225, Failures: 3, Errors: 0, Skipped: 215
Am 30.04.2016 um 22:03 schrieb Veit Guna:
> Hi Andrew.
>
> Thanks for looking into this!
>
> I've tried the 1.9.2 version and now the error below pops up. Google
> pointed me to:
>
> https://issues.apache.org/jira/browse/JCLOUDS-1015
>
> Which has seemed to fix the problem. I'm not sure whether this has made
> it into 1.9.2 - apparently not :)?
> I have to admit, that I have a german Windows version. So that matches
> the error and the fix.
>
> I'll try to look into the testcases tomorrow. Thanks so far!
>
>
> java.lang.RuntimeException:
> java.nio.file.attribute.UserPrincipalNotFoundException
> at
> org.jclouds.filesystem.strategy.internal.FilesystemStorageStrategyImpl.setBlobAccess(FilesystemStorageStrategyImpl.java:547)
> at
> org.jclouds.filesystem.strategy.internal.FilesystemStorageStrategyImpl.putBlob(FilesystemStorageStrategyImpl.java:464)
> at
> org.jclouds.blobstore.config.LocalBlobStore.putBlob(LocalBlobStore.java:487)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at java.lang.reflect.Method.invoke(Method.java:497)
> at
> com.google.inject.internal.DelegatingInvocationHandler.invoke(DelegatingInvocationHandler.java:37)
> .....
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at java.lang.reflect.Method.invoke(Method.java:497)
> Caused by: java.nio.file.attribute.UserPrincipalNotFoundException
> at org.jclouds.filesystem.util.Utils.setPrivate(Utils.java:83)
> at
> org.jclouds.filesystem.strategy.internal.FilesystemStorageStrategyImpl.setBlobAccess(FilesystemStorageStrategyImpl.java:542)
> ... 11 more
>
> Am 30.04.2016 um 21:46 schrieb Andrew Phillips:
>>> Based on the following, I suspect PUBLIC_READ may not work reliably on
>>> transient blobstores such as the filesystem provider, though:
>> Looks like I jumped the gun here a bit ;-) Do you see the same
>> behaviour with 1.9.2, i.e before the change you referred to with the
>> "Everyone lookup" was introduced?
>>
>> Regards
>>
>> ap
>
