Reverted in 86e947ddedfa1a13976f9debeadae1da6f2f0190.
---
Reply to this email directly or view it on GitHub:
https://github.com/jclouds/jclouds/pull/850#issuecomment-176616727
> 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_
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.
> 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 extende
`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-1335
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
Closed #850.
---
Reply to this email directly or view it on GitHub:
https://github.com/jclouds/jclouds/pull/850#event-388196209
> 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
>
