> Can you change this to always provide an ETag for consistency with real > blobstores? Currently we return the ETag if the putBlob request included > Content-MD5 or generate it if the filesystem does not support > UserDefinedFileAttributeView (Mac OS X, NFS mounts). We can either remove the > property and unconditionally provide ETag or keep the property and use it on > the non-UserDefinedFileAttributeView code path.
I'll happily remove the option. The current behavior is slightly different than you describe: the filesystem object store always computes the actual MD5 hash on puts when it writes the extended attribute. In further regrettable news, `getUserDefinedFileAttributeView` returns non-null on OSX, even though user extended attribute views are not actually supported by the JVM on that platform. Will remove the property and the conditional block. --- Reply to this email directly or view it on GitHub: https://github.com/jclouds/jclouds/pull/850#issuecomment-133180146
