Bitcasa, Google Drive & Phantom File Downloads
Updated December 20, 2012.
This site is no longer being maintained. Keep that in mind as you go through this page.
Bitcasa and Google Drive are two attractive choices for cloud storage. However, I found that both services preserve shared links when the linked file is deleted from the account. Not only is this behavior unique among top and even mid-level providers, it means, simply put, that you will still be sharing files when you thought you were not.
When I finished the tSc cloud storage comparison earlier this month, I had in my notes over two dozen different shared links to files hosted by various services. Sorting through these, I noticed that downloads for Bitcasa and Google Drive were still active, even though the linked files had been deleted. Hmm... I wanted to confirm this on a blank canvas so I loaded a fresh hard drive image of Windows 7 and created new Bitcasa and Google Drive accounts.
I used Bitcasa’s client software to uploaded a 10.5 MB Truecrypt container and then shared the file by creating a download link from the context menu. A TC container with a hopelessly impractical name like 10.5MBTruecryptcontainer89AOxizk4JUR89APU4N8 should have eluded Bitcasa’s deduplication tables because it’s extremely unlikely that someone else has that exact same file.
The next morning I used the client program to delete the Truecrypt file from the account. About 2 hours later, I checked to see if the link still worked. It did! I was able to download the file as if it was still alive and well in the Infinite folder. Between this new account I just created and the one I used for the cloud service article, I now have two Bitcasa share links which work perfectly even though I deleted the actual files in both Bitcasa accounts.
Bitcasa accounts do not have a Trash directory and when you delete a file in the local Bitcasa folder using their client program, it disappears instead of going to the Recycle Bin. I searched through every directory in the account to find my Truecrypt file. It wasn’t there. I used the search bar to locate by file name. No results. I considered that the link destination was attached to a file version that wasn’t being removed from the versioning system, but the two days the account was active in the version calendar showed no remains of my file.
To conclude, Bitcasa responded that they’re aware of this and are working on a fix, but they don’t have an estimate for when it would be implemented. Here is their further explanation:
"...basically the reason the share link is still active is because for that moment in time that version (snap shot) of the folder has been shared. Share links are linked to the versioning. So this share is a snapshot of that version in time independent of if that file has been changed."
So it turns out this is a problem with the versioning after all, something which cannot be disabled so there is nothing the you can do about it. I first noticed this in September but between all the open accounts and other things going on with the main cloud service article, I chalked it up to something I did wrong. Why do I mention that? Because this issue has been ongoing for at minimum, nearly four months.
Of all the services in the tSc cloud study, in addition to Box and Microsoft SkyDrive (which I tried just to see how they compared), none showed this same complication that Bitcasa had. However, I spotted Google Drive behaving similarly. That is, it will make shared links of deleted files available until you empty your Drive account’s trash folder. After which, the link will result in a 404 error. It’s a unique behavior among the 25 cloud storage services I examined.
The deceiving part about this is that when you delete the file through Drive’s client program, the file moves to the Windows Recycle Bin. The way Windows behaves is that a file in the Recycle bin means that file is no longer accessible by Word, VLC or whatever, and this has molded people's perception of what happens when you delete a file.
Yet when files which were shared on Drive were later deleted to the Recycle Bin, their download links were still active. The solution was to log into Google Drive through the web browser and empty the account’s trash there. Only then were the shared files totally inaccessible.
"This is actually intended behavior... What collaborators will see when an owner deletes a file is that the file resides in trash. It prompts to contact the owner to place the file back in inbox..."
Unfortunately, that has nothing to do with file sharing by public links, which is what I’m writing about here; a totally different story from private group access. Collaborators actually have no indication whatsoever that the file they’re working on is in the owner’s Trash. It’s removed entirely from their view.
By all appearances, this public link persistence seems to be just an oversight, but one with uncertain, if not no intention of being changed. The logical and expected behavior is that public link association should end when a file is sent to the Trash. To take it a step further, Drive’s trash directory should not be buried in a dropdown menu with zero indication it contains anything. To help make the user more aware of their account’s contents, Trash should appear in the left stationary menu with a content counter next to the label when there's anything in it.