"Everyone" in a french Windows is "Tout le monde".
Thus, the line.split(" ") returns only "Tout" and putBlob() throws an exception.
The modified regex search for the first two consecutive white char to return the name.
Windows's whoami returns a bunch of 0x20 between the name and the type.
Today the filesystem blobstore provider use the extended attributes of the
filesystem to store metadata. This is not always desirable as some filesystems
(such as NFSv3) do not support extended metadata. The current source code does
not allow to change this easily. getUserDefinedFileAttributeView could easily
be overriden for this purpose and allow extensions that customize where the
metadata should be stored.
See also JCLOUDS-658
This is a combination of 16 commits:
* First approach to ArbitraryCpuRamTemplateBuilderImpl
* Several fixes: refactoring some names, format, identation problems, some missing license headers and generateId method
* Refactored parse utility
* Added GoogleComputeEngineArbitraryCpuRamTemplateBuilderImpl to support GCE custom machine URI
* extracted hardware creation to automaticHardwareForCpuAndRam method
* Fixed ide automatic asterisk imports
* correcting WIP base case PR according to comments
* added machineTypeUriToHardware to set custom hardware in nodes
* fix checkstyle violations and other PR comments
* Set the providerId to custom machineType URI and fix adding node log
* Arbitrary hardware tests added to BaseTemplateBuilderLiveTest and GoogleComputeEngineTemplateBuilderLiveTest
* Added two more tests to BaseTemplateBuilderLiveTest
* Move repeated constants to TestUtils to reuse code
* Fix full path in the Hardware id and URI
* Add custom hardware tests to BaseComputeServiceLiveTest and GCEServiceLiveTest
* Change customHardware test to use buildTemplate and fix identation
On Windows, we need to avoid trailing spaces, as the test fails to
create the required blob. Specifically, we should not test blobs named
" " and "%20 ".
There is no notion of marker blobs in the file system blob store,
which means that when listing results after issuing the
"createDirectory" request, the marker blob will not be in the result
set.
When a filesystem blob does not have content metadata and when users
set jclouds.filesystem.auto-detect-content-type to tru, probe the file
type to return to clients. This is useful when using jclouds to serve
an existing filesystem.
