[
https://issues.apache.org/jira/browse/POLYGENE-223?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15896198#comment-15896198
]
Georg Ragaller commented on POLYGENE-223:
-----------------------------------------
??Access Denied on Windows on move that...??
That was my first thought also. But I checked that with Sysinternals handle.exe
tool. After more digging, it seems to be related to the ACL magic which is done
by jclouds on the container directory and the blob file itself.
On the machine where it fails, there are no write rights on the blob and if i
activate that just before before the rename it works.
I haven't jet debugged it on one of the the machines where it works to find out
the difference, but it may be related to the fact that on the failing machine I
work with a domain user.
> Unit tests for jclouds fail on a localized windows installation
> ---------------------------------------------------------------
>
> Key: POLYGENE-223
> URL: https://issues.apache.org/jira/browse/POLYGENE-223
> Project: Polygene
> Issue Type: Bug
> Affects Versions: 3.0
> Environment: awt.toolkit=sun.awt.windows.WToolkit
> file.encoding=Cp1252
> file.encoding.pkg=sun.io
> file.separator=\
> java.awt.graphicsenv=sun.awt.Win32GraphicsEnvironment
> java.awt.printerjob=sun.awt.windows.WPrinterJob
> java.class.path=.
> java.class.version=52.0
> java.endorsed.dirs=d:\java\jdk_x86_64\1.8.0\jre\lib\endorsed
> java.ext.dirs=d:\java\jdk_x86_64\1.8.0\jre\lib\ext;C:\Windows\Sun\Java\lib\ext
> java.home=d:\java\jdk_x86_64\1.8.0\jre
> java.io.tmpdir=C:\Users\geler\AppData\Local\Temp\
> java.library.path=d:\java\jdk_x86_64\1.8.0\bin;C:\Windows\Sun\Java\bin;C:\Windows\system32;C:\Windows;d:\java\jdk_x86_64\1.8.0\bin;;.
> java.runtime.name=Java(TM) SE Runtime Environment
> java.runtime.version=1.8.0_121-b13
> java.specification.name=Java Platform API Specification
> java.specification.vendor=Oracle Corporation
> java.specification.version=1.8
> java.vendor=Oracle Corporation
> java.vendor.url=http://java.oracle.com/
> java.vendor.url.bug=http://bugreport.sun.com/bugreport/
> java.version=1.8.0_121
> java.vm.info=mixed mode
> java.vm.name=Java HotSpot(TM) 64-Bit Server VM
> java.vm.specification.name=Java Virtual Machine Specification
> java.vm.specification.vendor=Oracle Corporation
> java.vm.specification.version=1.8
> java.vm.vendor=Oracle Corporation
> java.vm.version=25.121-b13
> line.separator=
> os.arch=amd64
> os.name=Windows 7
> os.version=6.1
> path.separator=;
> sun.arch.data.model=64
> sun.boot.class.path=d:\java\jdk_x86_64\1.8.0\jre\lib\resources.jar;d:\java\jdk_x86_64\1.8.0\jre\lib\rt.jar;d:\java\jdk_x86_64\1.8.0\jre\lib\sunrsasign.jar;d:\java\jdk_x86_64\1.8.0\jre\lib\jsse.jar;d:\java\jdk_x86_64\1.8.0\jre\lib\jce.jar;d:\java\jdk_x86_64\1.8.0\jre\lib\charsets.jar;d:\java\jdk_x86_64\1.8.0\jre\lib\jfr.jar;d:\java\jdk_x86_64\1.8.0\jre\classes
> sun.boot.library.path=d:\java\jdk_x86_64\1.8.0\jre\bin
> sun.cpu.endian=little
> sun.cpu.isalist=amd64
> sun.desktop=windows
> sun.io.unicode.encoding=UnicodeLittle
> sun.java.command=DumpSystemProperties
> sun.java.launcher=SUN_STANDARD
> sun.jnu.encoding=Cp1252
> sun.management.compiler=HotSpot 64-Bit Tiered Compilers
> sun.os.patch.level=Service Pack 1
> sun.stderr.encoding=cp850
> user.country=DE
> user.dir=d:\temp
> user.home=C:\Users\geler
> user.language=de
> user.name=geler
> user.script=
> user.timezone=
> user.variant=
> Reporter: Georg Ragaller
> Assignee: Paul Merlin
> Attachments: jclouds-test-summary-rename-problem.zip,
> jclouds-test-summary.zip
>
>
> When building from source, on my windows machine with locale DE the jclouds
> tests fail with the following exception as root cause (commit 9d16d5553 on
> the develop branch):
> {code:title=Stacktrace, for more see Attachment|borderStyle=solid}
> Caused by: java.nio.file.attribute.UserPrincipalNotFoundException
> at
> sun.nio.fs.WindowsUserPrincipals.lookup(WindowsUserPrincipals.java:147)
> at
> sun.nio.fs.WindowsFileSystem$LookupService$1.lookupPrincipalByName(WindowsFileSystem.java:270)
> at org.jclouds.filesystem.util.Utils.setPrivate(Utils.java:83)
> at
> org.jclouds.filesystem.strategy.internal.FilesystemStorageStrategyImpl.setContainerAccess(FilesystemStorageStrategyImpl.java:192)
> ... 41 more
> {code}
> A bit of investigation shows, that the currently used jclouds version tries
> to lookup a user principal with the name {{Everyone}}, but that doesn't work
> with a German locale (and probably with all other non English locales).
> [https://github.com/jclouds/jclouds/blob/rel/jclouds-1.9.2/apis/filesystem/src/main/java/org/jclouds/filesystem/util/Utils.java#L66]
> It looks like this problem was fixed with
> [https://github.com/jclouds/jclouds/commit/2efcb2c5a9fadc52bcac411898154735eea4a66a]
> My guess is, that this issue can be fixed by upgrading from jclouds 1.9.x to
> 2.0.x.
> Neither I'm experienced with gradle dependency management, nor the jclouds
> extension and the implications when upgrading. So I would leave that to the
> experts.
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)