Jump to content
  • 0

Amazon Cloud Drive - Why is it not supported?


Alex

Question

Some people have mentioned that we're not transparent enough with regards to what's going on with Amazon Cloud Drive support. That was definitely not the intention, and if that's how you guys feel, then I'm sorry about that and I want to change that. We really have nothing to gain by keeping any of this secret.
 
Here, you will find a timeline of exactly what's happening with our ongoing communications with the Amazon Cloud Drive team, and I will keep this thread up to date as things develop.
 
Timeline:

  • On May 28th the first public BETA of StableBit CloudDrive was released without Amazon Cloud Drive production access enabled. At the time, I thought that the semi-automated whitelisting process that we went through was "Production Access". While this is similar to other providers, like Dropbox, it became apparent that for Amazon Cloud Drive, it's not. Upon closer reading of their documentation, it appears that the whitelisting process actually imposed "Developer Access" on us. To get upgraded to "Production Access" Amazon Cloud Drive requires direct email communications with the Amazon Cloud Drive team.
  • We submitted our application for approval for production access originally on Aug. 15 over email:

Hello,
 
I would like to submit my application to be approved for production use with the Amazon Cloud Drive API.
 
It is using the "StableBit CloudDrive" security profile on the [...] amazon account. I'm sorry for the other extraneous security profiles on that account, but I've been having issues getting my security profile working, and I've been in touch with Amazon regarding that in a different email thread, but that's now resolved.
 
Application name: StableBit CloudDrive
Description: A secure virtual hard drive, powered by the cloud.
Web site: https://stablebit.com/CloudDrive
Operating system: Microsoft Windows
 
Summary:
An application for Microsoft Windows that allows users to create securely encrypted virtual hard drives (AES) which store their data in the cloud provider of their choice. Only the user has the key to unlock their data for ultimate security. We would like to enable Amazon Cloud Drive for production use with our application.
 
We are still in BETA and you can see the website for a more elaborate description of our application and its feature set.
 
Download *:

  • x64: [...]
  • x86: [...]
* Please don't download the version from stablebit.com as it does not have the correct code for Amazon Cloud Drive. We will update that version once we get approved.

 
System requirements:
  • Microsoft Windows Vista or newer.
  • A broadband always-on Internet connection.
  • An internal hard drive with at least 10 GB of freespace.
Testing notes:
  • If you're not sure whether you need the x64 or the x86 version, please download the x64 version. The x86 version is provided for compatibility with older systems.
How to use:

 
The application is designed to be very easy to use and should be self explanatory, but for the sake of completeness here are detailed instructions on how to use it.
  • Install the application.
  • The user interface will open shortly after it's installed. Or you can launch it from the Start menu under StableBit CloudDrive.
  • Click Get a license...
  • Activate the fully functional trial, or enter the following retail activation ID: {8523B289-3692-41C7-8221-926CA777D9F8-BD}
  • Click Connect... next to Amazon Cloud Drive.
  • Click Authorize StableBit CloudDrive...
  • A web browser will open where you will be able to log into your Amazon account and authorize StableBit CloudDrive to access your data.
  • Copy the Access Key that you are given into the application and enter a Name for this connection (it can be anything).
  • Now you will be able to click Create... to create a new virtual drive.
  • On the dialog that pops up, just click the Create button to create a default 10 GB drive.
Please let me know if you experience any issues or need any more information.

 
I look forward to getting our application approved for use with Amazon Cloud Drive.
 
Kind Regards,
Alex Piskarev
Covecube Inc.

 

  • On Aug 24th I wrote in requesting a status update, because no one had replied to me, so I had no idea whether the email was read or not.
  • On Aug. 27th I finally got an email back letting me know that our application was approved for production use. I was pleasantly surprised.

Hello Alex,
 
 
We performed our call pattern analysis this week and we are approving StabeBit CloudDrive for production. The rate limiting changes will take effect in the next couple minutes.
 
Best regards,
 
Amazon Cloud Drive 3P Support

  • On Sept 1st, after some testing, I wrote another email to Amazon letting them know that we are having issues with Amazon not respecting the Content-Type of uploads, and that we are also having issues with the new permission scopes that have been changes since we initially submitted our application for approval.

Amazon,
 
That's great news, and thank you for doing that. However, I am running into a small permission issue. The new Amazon read scopes are causing a problem with how our application stores data in the cloud. This wasn't an issue with earlier builds as they were using the older scopes.
 
At the heart of the problem is that the Content-Type: application/octet-stream is not being used when we, for example, upload what may look like text files to the cloud. All of our files can be treated as binary, but this behavior means that we need additional permissions (clouddrive:read_all) in order to access those files.
 
It turns out what we really need is: clouddrive:read_all clouddrive:write
 
This is for the "StableBit CloudDrive" security profile.
 
I know that those scopes were originally selected in the security profile whitelisting form, but how do I go about changing those permissions at this point?
 
Should I just re-whitelist the same profile?
 
Thank You,
Alex Piskarev
Covecube Inc.

  • No one answered this particular email until...
  • On Sept 7th I received a panicked email from Amazon addressed to me (with CCs to other Amazon addresses) letting me know that Amazon is seeing unusual call patterns from one of our users. 

Hi Alex,
 
We are seeing an unusual pattern from last 3-4 days. There is a single customer (Customer ID: A1SPP1QQD9NHAF ) generating very high traffic from stablebit to Cloud Drive (uploads @ the rate of 45 per second). This created few impacts on our service including hotspotting due to high traffic from single customer.
 
As a quick mitigation, we have changed the throttling levels for stablebit back to development levels. You will see some throttling exceptions until we change it back to prod level. We need your help in further analysis here. Can you please check what is happening with this customer/ what is he trying to do? Is this some sort of test customer you are using?
 
Regards,

  • On Sept 11th I replied explaining that we do not keep track of what our customers are doing, and that our software can scale very well, as long as the server permits it and the network bandwidth is sufficient. Our software does respect 429 throttling responses from the server and it does perform exponential backoff, as is standard practice in such cases. Nevertheless, I offered to limit the number of threads that we use, or to apply any other limits that Amazon deems necessary on the client side.

Amazon,
 
Thanks for letting me know that this is an issue. I did notice the developer throttling limits take effect.
 
Right now, our software doesn't limit the number of upload threads that a user can specify. Normally, our data is stored in 1 MB chunks, so theoretically speaking, if someone had sufficient upload bandwidth they could upload x50 1 MB chunks all at the same time.
 
This allows our software to scale to the user's maximum upload bandwidth, but I can see how this can be a problem. We can of course limit the number of simultaneous upload threads as per your advice.
 
What would be a reasonable maximum number of simultaneous upload threads to Amazon Cloud Drive? Would a maximum of x10 uploads at a time suffice, or we can lower that even further?
 
Thanks,
Alex

I highlighted on this page the key question that really needs answered. Also, please note that obviously Amazon knows who this user is, since they have to be their customer in order to be logged into Amazon Cloud Drive. Also note that instead of banning or throttling that particular customer, Amazon has chosen to block the entire user base of our application.

  • On Sept. 16th I received a response from Amazon.

Hello Alex,
 
 
Thank you for your patience. We have taken your insights into consideration, and we are currently working on figuring out the optimal limit for uploads that will allow your product to work as it should and still prevent unnecessary impact on Cloud Drive. We hope to have an answer for you soon.
 
Best regards,
 
Amazon Cloud Drive 3P Support

  • On Sept. 21st I haven't heard anything back yet, so I sent them this.

Amazon,
 
Thanks for letting me know, and I await your response.
 
Regards,
Alex

  • I waited until Oct. 29th and no one answered. At that point I informed them that we're going ahead with the next public BETA regardless.

Amazon,
 
We're going ahead with our next public BETA release. We will, for now, categorize your provider as "experimental". That means it won't show up in our list of available providers by default. We're going to release a new public BETA by the end of this week.
 
In that BETA, we will add an upload rate limit for Amazon Cloud Drive. It will never allow an upload rate of faster than 20 megabits per second. And this is the reason I'm writing to you, if that's too fast, please let me know and we'll change it to whatever is acceptable to you before the release.
 
After the BETA is out, I'll send you another email asking whether you can reinstate our production status.
 
Thank you,
Alex

  • Some time in the beginning of November an Amazon employee, on the Amazon forums, started claiming that we're not answering our emails. This was amidst their users asking why Amazon Cloud Drive is not supported with StableBit CloudDrive. So I did post a reply to that, listing a similar timeline.
  • One Nov. 11th I sent another email to them.

Amazon,
 
According to this thread on your forums, [...] from Amazon is saying that you can't get in touch with the developer of StableBit CloudDrive: [...]
 
I find this very interesting, since I'm the lead developer of StableBit CloudDrive, and I'm still awaiting your response from my last 2 emails.
 
In any case, we've released our next public BETA without Amazon Cloud Drive production access. This will likely be the last public BETA, and the next release may be the 1.0 Release final.
 
These are the limits that we've places on Amazon Cloud Drive, on the client side:
Maximum DL: 50 Megabits /s
Maximum UL: 20 Megabits /s
Maximum number of UL connections: 2
Maximum number of DL connections: 4
As I've said before, we can change these to anything that you want, but since I haven't received a response, I had to make a guess.
 
Of course, we would like you to approve us for production access, if at all possible.
 
Our public BETA is available here: https://stablebit.com/CloudDrive
 
To gain access to the Amazon Cloud Drive provider:
Click the little gear at the top of the StableBit CloudDrive UI.
Select Troubleshooting
Check Show experimental providers
You'll then see Amazon Cloud Drive listed in the list of providers.
 
The current public BETA is using the above limits for Amazon Cloud Drive, but the "StableBit Applications" security profile is currently not approved for production use.
 
If you can please let me know if there's anything at all that we can do on our end to get us approved as quickly as possible, or just write back with a status update of where we stand, I would highly appreciate it.
 
Thank You,
Alex

  • On Nov 13th Amazon finally replied.

Hello Alex,
 
Thank you for your emails and for providing details on the issue at hand. Looks like we've gotten a little out of sync! We would like to do everything we can to make sure we continue successfully integrating our products.
 
In terms of your data about bandwidth and connections, do you have those figures in terms of API calls per second? In general, a client instance on developer rate limits should make up to about [...] read and [...] write calls per second. On the production rates, they could go up to roughly [...] read and [...] write calls per second.
 
Thank you for providing a new Beta build, we will be testing it out over the weekend and examining the traffic pattern it generates.
 
Best regards,
Amazon Cloud Drive 3P Support

I redacted the limits, I don't know if they want those public.

  • On Nov. 19th I sent them another email asking to clarify what the limits mean exactly.

Amazon,
 
I'm looking forward to getting our app approved for production use, I'm sure that our mutual customers would be very happy.
 
So just to sum up how our product works... StableBit CloudDrive allows each of our users to create 1 or more fully encrypted virtual drives, where the data for that drive, is stored with the cloud provider of their choosing.
 
By default, our drives store their data in 1 MB sized opaque chunks in the provider's cloud store.
 
And here's the important part regarding your limits. Currently, for Amazon Cloud Drive we have limited the Download / Upload rate per drive to:
 
Upload: 20 Megabits/s (or 2.5 Megabytes/s)
Download: 50 Megabits/s (or 6.24 Megabytes/s)
 
So, converting that to API calls:
 
Upload: about 2.5 calls/s
Download: about 6.25 calls/s
 
And, let's double that for good measure, just to be safe. So we really are talking about less than 20 calls/s maximum per drive.
 
In addition to all of that, we do support exponential backoff if the server returns 429 error codes.
 
Now one thing that isn't clear to me, when you say "up to roughly [...] read and [...] write calls per second" for the production limits, do you mean for all of our users combined or for each Amazon user using our application? If it's for all of our users combined, we may have to lower our limits dramatically.
 
Thank you,
Alex

  • On Nov 25th Amazon replied with some questions and concerns regarding the number of API calls per second:

Hello Alex,
 
We've been going over our analysis of StableBit. Overall things are going very well, and we have a few questions for you.

  • At first we were a little confused by the call volume it generated. Tests working with less than 60 files were ending up being associated with over 2,000 different API calls. Tests designed to upload only were causing hundreds of download calls. Is it part of the upload process to fetch and modify and update 1Mb encrypted chunks that are already uploaded? Or maybe the operating system attempting to index it's new drive?
  • What kind of file size change do you expect with your encryption? ~100Mb of input files became ~200Mb worth of encrypted files. This is not a problem for us, just wondering about the padding in the chunks. 
  • In regards to call rates, things look to be right in line. You quoted that uploads and downloads should combine to be calling at 7.75 calls per second. Taking a histogram of the calls and clustering them by which second they happened in gave us good results. 99.61% of seconds contained 1-7 calls!
Best regards,
 
Amazon Cloud Drive 3P Support

 

Amazon
 
Glad to hear back from you. Here are your answers and I have some good news regarding the calls per second that StableBit CloudDrive generates on uploads.
 
First, your answers:

  • Regarding the calls per second:
    • The key thing to understand is, StableBit CloudDrive doesn't really know anything about local files. It simply emulates a virtual hard drive in the kernel. To StableBit CloudDrive, this virtual drive looks like a flat address space that can be read or written to. That space is virtually divided into fixed sized chunks, which are synchronized with the cloud, on demand.
    • So calls to the Amazon API are created on demand, only when necessary, in order to service existing drive I/O.
    • By default, for every chunk uploaded, StableBit CloudDrive will re-download that chunk to verify that it's stored correctly in the cloud. This is called upload verification and can be turned off in Drive Options -> Data integrity -> Upload verification. This will probably explain why you were seeing download requests with tests only designed for uploading. We can turn this off permanently for Amazon Cloud Drive, if you'd like.
    • It is possible that an upload will generate a full chunk download and then a full re-upload. This is done for providers that don't have any way of updating a part of a file (which are most cloud providers).
    • As far as the calls / second on uploads, I think that we've dramatically decreased these. I will explain in a bit.
  • Regarding the size change when encrypted.
    • There is very negligible overhead for encrypted data (< 0.01 %). 
    • 100 MB of encrypted data stays at roughly 100 MB of data. It's simply encrypted with AES256-CBC with a key that only the user knows.
----

 
Regarding the calls per second on uploads, our latest builds implement large chunk support (up to 100 MB) for most providers, including Amazon Cloud Drive. This should dramatically decrease the number of calls per second that are necessary for large file uploads.
 
As a point of comparison, to Google Drive for example, they are limiting us to 10 calls / second / user, which is working well but we can probably even go lower.
 
The large chunk support was implemented in 1.0.0.421, and you can download that here:
http://dl.covecube.com/CloudDriveWindows/beta/download/
 
If you want to really dig into the details of how I/O works with us, or get more information on large chunk support, I made a post about that here:
http://community.covecube.com/index.php?/topic/1622-large-chunks-and-the-io-manager/
 
Again, thank you very much for taking the time to evaluate our product, and please let me know what the next steps should be to get to production access and whether you need any changes or additional limits applied on our end.
 
Kind Regards,
Alex
Covecube Inc.

 

  • On Dec. 10th 2015, Amazon replied:

Hello Alex,
 
 
Thank you for this information. We are running a new set of tests on the build you mentioned, 1.0.0.421. Once we have those results, we can see what we want to do with Upload Verification and/or setting call limits per second per user.
 
Your details about file size inflation don't match with what we saw in our most recent tests. We'll try a few different kinds of upload profiles this time and let you know what we see. 
 
Thank you for your continued patience as we work together on getting this product to our customers.
 
 
Best regards,
 
Amazon Cloud Drive 3P Support

  • I have no idea what they mean regarding the encrypted data size. AES-CBC is a 1:1 encryption scheme. Some number of bytes go in and the same exact number of bytes come out, encrypted. We do have some minor overhead for the checksum / authentication signature at the end of every 1 MB unit of data, but that's at most 64 bytes per 1 MB when using HMAC-SHA512 (which is 0.006 % overhead). You can easily verify this by creating an encrypted cloud drive of some size, filling it up to capacity, and then checking how much data is used on the server.

    Here's the data for a 5 GB encrypted drive:

    xPSzCl1.png

    Yes, it's 5 GBs.

 

 


Hello Alex,
 
We have an update and some questions regarding our analysis of build 1.0.0.421. 
 
This particular test involved a 1.5Gb folder containing 116 photos. The client ran for 48 hours before we stopped it. In each of those 48 hours, the client generated 104-205 calls, with an average of 168. (Down from ~12,000 in previous tests.)
 
Afterwards, we checked the test account through the browser. There are 163 files in the StableBit folder. 161 of them are chunk files. 8 chunks are 10 Mb in size. The remaining 153 chunks are 0 Bytes in size. Approximately half of all calls being made in each hour are resulting in errors. We tracked the request_ids of the errored calls into our logs and found many errors similar to this one:
 
        NameConflictException: Node with the name c71e006b-d476-45b4-84e0-91af15bf2683-chunk-300 already exists under parentId 0l1fv1_kQbyzeme0vIC1Rg conflicting NodeId: p8-oencZSVqV-E_x2N6LUQ
 
If this error is familiar you, do you have any recommendations for steps we might have missed in configuration, or a different build to try? 
 
Best regards,
Amazon Cloud Drive 3P Support 
 
To clarify the error issue here (I'm not 100% certain about this), Amazon doesn't provide a good way to ID these files. We have to try to upload them again, and then grab the error ID to get the actual file ID so we can update the file.  This is inefficient and would be solved with a more robust API that included a search functionality, or a better file list call. So, this is basically "by design" and required currently. 
-Christopher
 
 
Unfortunately, we haven't pursued this with Amazon recently. This is due to a number of big bugs that we have been following up on.  However, these bugs have lead to a lot of performance, stability and reliability fixes. And a lot of users have reported that these fixes have significantly improved the Amazon Cloud Drive provider.  That is something that is great to hear, as it may help to get the provider to a stable/reliable state. 
 
That said, once we get to a more stable state (after the next public beta build (after 1.0.0.463) or a stable/RC release), we do plan on pursuing this again.  
 
But in the meanwhile, we have held off on this as we want to focus on the entire product rather than a single, problematic provider. 
-Christopher
 
 
Amazon has "snuck in" additional guidelines that don't bode well for us. 
  • Don’t build apps that encrypt customer data

 

What does this mean for us? We have no idea right now.  Hopefully, this is a guideline and not a hard rule (other apps allow encryption, so that's hopeful, at least). 

 

But if we don't get re-approved, we'll deal with that when the time comes (though, we will push hard to get approval).

 

- Christopher (Jan 15. 2017)

 

If you haven't seen already, we've released a "gold" version of StableBit CloudDrive. Meaning that we have an official release! 
Unfortunately, because of increasing issues with Amazon Cloud Drive, that appear to be ENTIRELY server side (drive issues due to "429" errors, odd outages, etc), and that we are STILL not approved for production status (despite sending off additional emails a month ago, requesting approval or at least an update), we have dropped support Amazon Cloud Drive. 

This does not impact existing users, as you will still be able to mount and use your existing drives. However, we have blocked the ability to create new drives for Amazon Cloud Drive.   

 

This was not a decision that we made lightly, and while we don't regret this decision, we are saddened by it. We would have loved to come to some sort of outcome that included keeping full support for Amazon Cloud Drive. 

-Christopher (May 17, 2017)

Edited by Christopher (Drashna)
Cleaned up Quote info to make more readable, Added Release/Gold notification
Link to comment
Share on other sites

Recommended Posts

  • 0

Hey all, just catching up on this thread. Any new developments? At $60/year for unlimited storage i think this is the only deal out there like that. I have ~20TB that i keep backed up locally right now that i would like to move the the cloud

Actually, there is! Jottacloud a Norwegian cloud provider have unlimited speed, space and they are even a bit cheaper than ACD. :) BUT lacking support in Cloud Drive atm.

 

 

 

Sent from my iPhone using Tapatalk

Link to comment
Share on other sites

  • 0

I know ACD is capped with the upload speed but are there any tips to maximize the performance. Mine is all over the place but usually only like 3MB/s

 

Maximum DL: 50 Megabits /s
Maximum UL: 20 Megabits /s
Maximum number of DL connections: 4
Maximum number of UL connections: 2
 
 
So, what you're seeing is fairly close to what we'd expect here. 

 

Not sure we can really improve that. 

 

However, increasing the "minimum download size" may help here, though increase latency of the drive. 

 

Sorry to beat a dead horse here, but is there an ETA on ACD support? I've uploaded several TBs with your client, but it now seems increasingly unresponsive to the point where I wonder if I'll be able to get my data back.

 

We plan on pushing the issue once we have a stable/release build for StableBit CloudDrive.

 

Until then... no, we don't have an ETA.  however, the outlook isn't good, see below.on 16 Dec 2016 - 04:50 AM, said:

Well you WERE using a beta product.

 

At this point I don't expect ACD support to ever be anything more than a somewhat functioning prototype. Plex just recently dropped support for ACD for their cloud offering and added all the other big providers that are more reliable.

 

beta or not, data is data, and people have expectations here (that Google has NOT helped with, with their perpetual betas). 

 

As for ACD, yeah, I saw the Plex announcement.  

 

I also saw reports of Amazon closing accounts because of this.  And I'm sure we can guess why. 

 

 

 

That said, Amazon has quietly changed their developer guidelines. 

 

 

What Not to Build

[...]

  • Don’t build apps that encrypt customer data

 

This additional was not really announced, noted or anything. It was slipped in, and people have only recently started to notice. 

 

Since all of the data is obfuscated, at the very least, the implications are not good.

 

This is despite the fact that their showcase includes a number of apps that do support encryption, and despite comments about "really wanting our app to succeed". 

 

 

 

 

But no, we don't know what this means for the future of StableBit CloudDrive.  

Link to comment
Share on other sites

  • 0

beta or not, data is data, and people have expectations here (that Google has NOT helped with, with their perpetual betas). 

 

As for ACD, yeah, I saw the Plex announcement.  

 

I also saw reports of Amazon closing accounts because of this.  And I'm sure we can guess why. 

 

 

 

That said, Amazon has quietly changed their developer guidelines. 

 

 

This additional was not really announced, noted or anything. It was slipped in, and people have only recently started to notice. 

 

Since all of the data is obfuscated, at the very least, the implications are not good.

 

This is despite the fact that their showcase includes a number of apps that do support encryption, and despite comments about "really wanting our app to succeed". 

 

 

 

 

But no, we don't know what this means for the future of StableBit CloudDrive.  

 

Anyone who expects to use a product that has a feature that you have to exclusively enable because its known to be unstable and not reliable is a bit delusional. I find it absurd that people actually used it for anything other than testing, or throwing data into it that you don't care if you lose. 

 

Just my two cents. 

Link to comment
Share on other sites

  • 0

 

Maximum DL: 50 Megabits /s
Maximum UL: 20 Megabits /s
Maximum number of DL connections: 4
Maximum number of UL connections: 2
 
 
So, what you're seeing is fairly close to what we'd expect here. 

 

Not sure we can really improve that. 

 

However, increasing the "minimum download size" may help here, though increase latency of the drive. 

 

 

 

Ah my bad, I read that backwards, I was reading the upload as 50Mb/s

 

although since then it has dropped. it is only going between 700KB/s and 1MB/s. Id be happy(ish) if I could get a steady 20mbit (2.5MB/s) it is going to take forever at this speed

 

Edit: although after reading the plex news amazon might not be the way to go. Which stinks since they had the best deal.

Link to comment
Share on other sites

  • 0

Hi I also read about plex dropping amazon, has anybody ever thought that's these providers don't want users storing massive amounts of data let alone using them as there own personal Netflix streamer and apps such as plex and cloud drive will never function 100% as it's not what the cloud providers intended there storage to be used for. even cloud backup users with lots of data get booted every now and then. This has to be looked at a different way Netflix must pay huge sums to run and store there data in the cloud so why are they going to sit by and let people do the same for £50 a year never going to happen

Link to comment
Share on other sites

  • 0

Netflix store once and use a lot of bandwidth, this scenario is same bandwidth and if encrypted storing a copy for everyone well am oversimplification. Unless storage gets to be a lot cheaper unlimited is not going to make money. How they ever thought Plex DVR support was a good idea amazed me. This has damaged the Amazon storage name. There are angry Plex users, unmitigated disaster for everyone involved. Whoever is running that Amazon cloud drive circus needs the boot and roll it into Amazon S3 or just kill it. Clearly they can't even take a basic users idea of unlimited. What the hell did they think Plex DVR users were going to do, upload one program a week. I'm thinking anyone who developed for this platform is burning time and good will until Amazon sorts this service out. If there are limited spell them out and make the service reliable or shut up shop. It really is beyond a joke.

 

Sent from my Nexus 6P using Tapatalk

Link to comment
Share on other sites

  • 0

I've just downloaded the scanner and pool products and am getting started using them.  So far I'm liking what I see.  Looking at the CloudDrive product touches on something I considered for some time and something I'd like to use once I've finished setting up my pools.  

 

Like so many who have posted on this thread I don't have a lot of money for cloud storage.  The ACD price point is very hard to ignore.  As I've read through this thread and a little research on ACD I can see that other products are having challenges with it too.  I can also understand the Dev's desire to focus on core product functionality at this point in the dev cycle and come back to ACD when they can.  That said, the ACD price point is very hard to ignore. :o  And not being one to give up quickly I'm hoping the politically incorrect idiom, "There's more than one way to skin a cat." might apply here. 

 

Has anyone tried using a 3rd party app such as WebDrive or ExpanDrive between ACD and CloudDrive?  I get that it is a little kludgy but if the utility acts as a middleware that can make the cloud storage show up as a drive in Windows Explorer can CloudDrive not be configured to use that drive maintaining encryption?  As I said, I haven't gotten this far yet but would like to know if this is a viable option and if so, how well has it worked for those who've tried. 

 

Do have one potentially larger concern and that is Drashna's post about ACD pushing away from encrypted content.  Haven't read much on the Plex ACD fun but before I do anything with CloudDrive or ACD I do want to get a better feeling if Amazon is going to allow encrypted drive content.  This would be the bulk of my content on ACD.

 

Thanks to all and Merry Christmas.

 

EDIT: Okay, I've had a chance to download CloudDrive and work with it a bit.  I was mistakenly (my fault) under the impression there was an integration between PoolDrive and CloudDrive.  Specifically, I thought you could set CloudDrive up as a backup or replication destination for Drive Pools.  With a better understanding of the product I withdraw my WebDrive/ExpanDrive question.  Guess while I'm here I'll make a feature request.  :)

 

Thanks much.

Link to comment
Share on other sites

  • 0

Hi Ian,

 

Yes, I have read them and it is a shame that Amazon is not living up to it's potential or even brand name. However, I am not seeing any "no, let's leave this" or "now let us pursue this in another way", hence the question.

I for one is very happy now after fiddling around with the setup to get everything working according to expectation, but the throttling is somewhat bothersome.

 

BR

Fredrik

Link to comment
Share on other sites

  • 0

Fredrick, they are a very talented and smart group of programmers the problem seems that in summary that Amazon drive are isolated from the excellent Amazon S3 team and they keep Channing the rules. I think their idea of unlimited is different to ours. I don't believe the concept was well thought out and the team is not up to the task at Amazon drive. All other Amazon services I have touched are well recorded and professional. That's not what I see with the drive term. Find give friends and share a Google apps account and the unlimited data add-on. That's what I would do if I had 5 people who I knew who trusted me and would use the service. As true unlimited broadband is not common in Australia at high speeds is only stuff most people could dream of even if they had unlimited storage. I assume Google apps drive unlimited is reliable.

 

Sent from my Nexus 6P using Tapatalk

Link to comment
Share on other sites

  • 0

Any news or progress on getting Amazon from Experimental to ordinary, I.e. getting out of developer mode?

​BR

 

Fredrik

 

Nope, and there probably won't be until we press the issue. 

 

That said, we don't plan on pressing it until after we have a stable release of StableBit CloudDrive.  And that should be "very soon", hopefully.

 

 

Though, worse here, is that Amazon did "sneak in" an update to their developer guidelines.... that they don't want to support any app with encrypted data. 

 

Since all of our data is obfuscated, at the very least (ESPECIALLY for Amazon Cloud Drive), the outlook for approval is ... fairly grim.  

 

 

That said: 

 

[...] The ACD price point is very hard to ignore.  [...]

 

This is absolutely spot on. And it's one of the most disappointing things about this entire issue.   

 

We want this to work just as much (if not more) than you guys.  And that Amazon is making this so difficult is incredibly frustrating. 

 

As for other apps, I know of at least one other app that has been outright blocked by Amazon Cloud Drive, likely due to supporting encryption...

Link to comment
Share on other sites

  • 0

 

Though, worse here, is that Amazon did "sneak in" an update to their developer guidelines.... that they don't want to support any app with encrypted data. 

 

Since all of our data is obfuscated, at the very least (ESPECIALLY for Amazon Cloud Drive), the outlook for approval is ... fairly grim.  

 

 

I am very sad to hear that - all though I understand that parts of their business models are based on matching files and avoiding double-storage, I.e. limiting storage cost, it would mean that I, and probably many with me, need to rethink the strategy vs. Amazon. I like your product since it fits my purposes so I will continue using it, but I think you would do us all favor to take the discussion on above note with Amazon now to either put a period to the discussion (I.e. they will be removed as supplier) or to get them to accept the setup. This in turn would push my own decision going forward which I rather do now than later.

BR

 

Fredrik

 

 

Link to comment
Share on other sites

  • 0

I skimmed through the older posts but missed comments on this, so I apologize if this is already answered, but has something been changed in the very latest version of CloudDrive in regards to the creation of drives on Amazon?

 

I installed the latest version of CloudDrive and was able to connect to my already established drive with no problems (I created one drive on beta 631). That's normal behavior, but I was also able to create a new 10tb drive, seemingly without issue on version 802. I was under the impression that the new versions were unable to do this since Amazon would ask for a developer key or something which would prevent new versions of CloudDrive from creating new drives. Has this changed?

 

Also, this is a more general question, but is there any performance issues with using one drive between multiple computers? If I had 3 or so computers all hooked up to a single drive on CloudDrive, modifying and/or using the contents of that drive simultaneously, would that cause any major issues or possible data loss?

Link to comment
Share on other sites

  • 0

Yeah, I beleive that Alex has fixed the account login "issue", so it isn't necessary anymore. But it's been a while since I checked.

 

As for multiple computers loading the same drive... this is a corruption issue.  

Basically because we use a cache, there isn't a good way to sync this between systems in a way that avoids corrupting data. 

 

That said, you can set up something locally (such as SeaFile) to access the data from other systems. 

Link to comment
Share on other sites

  • 0

Yeah, I beleive that Alex has fixed the account login "issue", so it isn't necessary anymore. But it's been a while since I checked.

 

As for multiple computers loading the same drive... this is a corruption issue.  

Basically because we use a cache, there isn't a good way to sync this between systems in a way that avoids corrupting data. 

 

That said, you can set up something locally (such as SeaFile) to access the data from other systems. 

 

 

That's great to hear. It'll be nice to use the latest version without worrying about keeping the old versions around. I wasn't too keen on buying a license for the virtual machine where I kept version 631.

Link to comment
Share on other sites

  • 0

Hey everyone, I'm new to this program and I have a question. How do I get the files to upload? I have 114 gigs waiting to be uploaded but it's not starting.

 

 

It should "just work". 

 

If it's not, it's likely because it's being throttled, and blocked.

 

I think you've already posted this in a ticket, but grabbing logs should help us to identify why it's not uploading. 

Link to comment
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Guest
Answer this question...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

Loading...
×
×
  • Create New...