You are viewing a plain text version of this content. The canonical link for it is here.
Posted to notifications@jclouds.apache.org by Nate Rosenblum <no...@github.com> on 2015/08/20 20:57:41 UTC
[jclouds] Optionally compute Etag in filesystem provider (#850)
Adds a property that instructs filesystem object store providers to
compute the ETag on demand when the content-md5 is not available in
an extended attribute. Defaults to 'false', preserving existing
behavior.
You can view, comment on, or merge this pull request online at:
https://github.com/jclouds/jclouds/pull/850
-- Commit Summary --
* Optionally compute Etag in filesystem provider
-- File Changes --
M apis/filesystem/src/main/java/org/jclouds/filesystem/FilesystemApiMetadata.java (2)
M apis/filesystem/src/main/java/org/jclouds/filesystem/reference/FilesystemConstants.java (3)
M apis/filesystem/src/main/java/org/jclouds/filesystem/strategy/internal/FilesystemStorageStrategyImpl.java (7)
M apis/filesystem/src/test/java/org/jclouds/filesystem/FilesystemBlobStoreTest.java (1)
M apis/filesystem/src/test/java/org/jclouds/filesystem/strategy/internal/FilesystemStorageStrategyImplTest.java (46)
-- Patch Links --
https://github.com/jclouds/jclouds/pull/850.patch
https://github.com/jclouds/jclouds/pull/850.diff
---
Reply to this email directly or view it on GitHub:
https://github.com/jclouds/jclouds/pull/850
Re: [jclouds] Always return ETag in filesystem object store get
response (#850)
Posted by Nate Rosenblum <no...@github.com>.
> LocalBlobStore calls getBlob on the storage strategy during listContainer, this change will make it unbearably slow for the cases when the md5 needs to be generated at run time.
That's unfortunate, though it looks like this patch simply closed a corner case on OS X, where the user extended attribute view is non-null but still extended attributes are not supported; on a system where `getUserDefinedFileAttributeView` was returning null anyway, we'd already have recomputed the hash.
I'm honestly fine with behavior going either way, but would prefer uniformity.
---
Reply to this email directly or view it on GitHub:
https://github.com/jclouds/jclouds/pull/850#issuecomment-133583527
Re: [jclouds] Always return ETag in filesystem object store get
response (#850)
Posted by Andrew Gaul <no...@github.com>.
Reverted in 86e947ddedfa1a13976f9debeadae1da6f2f0190.
---
Reply to this email directly or view it on GitHub:
https://github.com/jclouds/jclouds/pull/850#issuecomment-176616727
Re: [jclouds] Always return ETag in filesystem object store get
response (#850)
Posted by Ka-Hing Cheung <no...@github.com>.
`LocalBlobStore` calls getBlob on the storage strategy during listContainer, this change will make it unbearably slow for the cases when the md5 needs to be generated at run time.
---
Reply to this email directly or view it on GitHub:
https://github.com/jclouds/jclouds/pull/850#issuecomment-133578347
Re: [jclouds] Always return ETag in filesystem object store get
response (#850)
Posted by Nate Rosenblum <no...@github.com>.
> The case I am concerned about is when jclouds is used to expose files not written through jclouds. In those cases getUserDefinedFileAttributeView() would not return null but the extended attribute would not have been written.
I'm fine with it if you'd like to revert this change. I _would_ like to understand why the expected null view is not in fact null on OS X, but I can approach that separately.
---
Reply to this email directly or view it on GitHub:
https://github.com/jclouds/jclouds/pull/850#issuecomment-133764166
Re: [jclouds] Optionally compute Etag in filesystem provider (#850)
Posted by Andrew Gaul <no...@github.com>.
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.
---
Reply to this email directly or view it on GitHub:
https://github.com/jclouds/jclouds/pull/850#issuecomment-133155764
Re: [jclouds] Always return ETag in filesystem object store get
response (#850)
Posted by Andrew Gaul <no...@github.com>.
Pushed to master as 496e27f1afa32b90d0656c3f21387cf68a30cb31. Thank you for your contribution @flandr!
---
Reply to this email directly or view it on GitHub:
https://github.com/jclouds/jclouds/pull/850#issuecomment-133188107
Re: [jclouds] Always return ETag in filesystem object store get
response (#850)
Posted by Andrew Gaul <no...@github.com>.
Closed #850.
---
Reply to this email directly or view it on GitHub:
https://github.com/jclouds/jclouds/pull/850#event-388196209
Re: [jclouds] Always return ETag in filesystem object store get
response (#850)
Posted by Nate Rosenblum <no...@github.com>.
> 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
Re: [jclouds] Always return ETag in filesystem object store get
response (#850)
Posted by Ka-Hing Cheung <no...@github.com>.
The case I am concerned about is when jclouds is used to expose files not written through jclouds. In those cases getUserDefinedFileAttributeView() would not return null but the extended attribute would not have been written.
---
Reply to this email directly or view it on GitHub:
https://github.com/jclouds/jclouds/pull/850#issuecomment-133762592
Re: [jclouds] Optionally compute Etag in filesystem provider (#850)
Posted by Nate Rosenblum <no...@github.com>.
I've left this optional to preserve existing behavior; would happily remove the property and do this by default if suggested.
---
Reply to this email directly or view it on GitHub:
https://github.com/jclouds/jclouds/pull/850#issuecomment-133119378