You describe The “Free Way” in syncing files to Amazon Drive, “Let’s say I have a folder called Free NASA Posters on my Desktop that I want to backup to my new Amazon Drive account. I can create a place for it within my odrive folder and cut-and-paste the files from my Desktop into the new location.”
What happens if instead of cutting and pasting, you copy and paste?
Is it possible to cut and paste (or copy and paste) the entire contents of My Documents, and work out of the odrive folder “my documents” to sync with Amazon Drive?
Yes, you can Copy and Paste no problem. So let’s say you copy your stuff from: C:\Users\MyUser\My Documents
And paste all of those files into: C:\Users\MyUsers\odrive\Amazon Cloud Drive\my documents
Now you’ll have two sets/copies of the files (one set in the original C:\Users\MyUser\My Documents folder which doesn’t sync and one set in the C:\Users\MyUsers\odrive\Amazon Cloud Drive\my documents folder which does sync since it’s within your odrive folder.
So now you can work out of C:\Users\MyUsers\odrive\Amazon Cloud Drive\my documents directly since that folder syncs with your Amazon Drive. In this situation, you could keep all of your files in the original location as well, but since the original location doesn’t sync and you’re not working out of there anymore, there’s no point. I wouldn’t want to keep juggling multiple copies of stuff so that’s why I suggested cut-and-paste.
It sure is possible to paste the entire contents of C:\Users\MyUser\My Documents into a folder my documents in your Amazon Drive and then work out of it from now on (e.g. you paste the files into C:\Users\MyUsers\odrive\Amazon Cloud Drive\my documents which will continue to sync with your remote location on Amazon, which is All > Amazon Cloud Drive > my documents as seen in Amazon Drive’s web client).
Now, if you wanted to just work directly out of the original folder for some reason and couldn’t work out of the folder in odrive, you have the option of using the Premium Sync to odrive option to set up a direct sync relationship between C:\Users\MyUser\My Documents and All > Amazon Cloud Drive > my documents… this isn’t a common restriction, but some people absolutely need to be able to have sync from their original location directly.
Yes, when you drag everything into the My Documents folder in odrive, we will try to sync the contents of the C:\Users\MyUser\odrive\Amazon Cloud Drive\My Documents\ folder with the remote My Documents folder on your Amazon Drive.
More specific details:
Any new files that have made it into your My Documents since your trial expired will get synchronized to your Amazon Drive.
It will not create duplicates of files.
If you have made file changes/edits, those files will get synchronized.
If a file is basically the same file, it will be considered to be in sync already, so we’ll efficiently decide to ignore it.
I think what I am more concerned with is Accidental Bad replication… If I’m working from a local copy and its syncing changes, thats one thing, but what happens if I am cleaning out my sync folder and I accidentally delete said local copy of the file I was working on? How long before that delete happens to the cloud copy? I think my fear in going to a “sync” method versus a traditional backup method is its not very clear how things behave when local deletes happen in a sync scenario. if file deletes are also synced, then how can I use odrive to also do cold backups to Amazon drive in this case?
Sync is definitely not the same as traditional backup, so you will want to take that into account in terms of expected behavior, @JeffL has covered that in the previous responses and in his blog post. There was also a discussion I had in this post that goes into some of my thoughts on backup vs sync and how I use “sync to odrive”: https://forum.odrive.com/t/backup-one-way-sync/1058/11
Just from a basic functionality standpoint, odrive comes with a delete safeguard built-in called the “odrive trash”. It essentially holds deletes from being sent to the cloud unless the user explicitly empties the odrive trash, or has previously enabled auto trash rules. More on that stuff here:
So In my learning and feeling out, I think I experienced a side-effect of this which you referenced above. I have a Mac Pro which uses the Photo app to collect all of my pictures from phones, tablets, etc etc. Since apple is apple, they do not have native hooks into Photo for anything but iCloud. So I highlighted all of my albums and exported them to the “Amazon Drive” folder, that is, the native client. Well that was terrible, and it was uploading one picture at a time. So, I decided to stop that sync, and I was going to then move them into the odrive Amazon Cloud drive landing point. Well in between the stop and the move, stuff started to get deleted, so only part that didn’t get deleted by the native app moved to Odrive. Then, Odrive started to sync and it deleted a bunch of stub folders to make it look like what I believe it truly had locally to sync.
I didn’t do much in the way of investigating this. I just re-exported the entire photo library to the odrive landing point and hoped it knew what to do with duplicates…
but I guess the question I have is, when I unsync I have the .cloudf files in place. this means that there is only a stub and the real source file is gone. Now, what happens then the .cloudf file is deleted, since this is what was loaded up in the odrive trash bin? are only local stubs deleted, or are those deletes taking place in amazon cloud drive?
Photos is a good example of how I want to use cloud. My files are already structured in a sense by an application, but I can’t natively hook into that app. So, if I wanted to export 2 new photo albums from photo into odrive, it would write the files locally, but once that happens I want the local copies gone. It seems like when I manually issue a sync, like you said, its a full. so yes, it does push everything up that wasn’t there but it also pulls everything down that I cleaned off… I’m guessing the backup functionality is going to be my solution to this, because I literally want to lift and shift the data. if I have stubs pointing back, thats all I need, but I don’t want to mirror the whole picture library back and forth (Comcast meters now…)
I should add, I am currently a just cloud customer, and a one direction sync is exactly what I do., it pushes up adds and changes, but not deletes and this has been an effective way for me to work for years. Justcloud is just a little too expensive the way they price themselves (they too don’t play nice with others, I wish odrive could integrate with them). So oDrive+Amazon/Google Drive is currently what I’m looking at as a JustCloud replacement. It might be 2 providers and some middleware, but combined its still cheaper than JustCloud for me at this point.
Placeholder files (.cloud and .cloudf) are representations of your cloud data. The local operations you take on those, like rename, move, and delete, will be performed on the remote data too. Delete is a special case, though, since odrive will hold that “command” in the odrive trash until the user empties it. When the odrive trash is emptied, anything that was “held” there will now be deleted in the cloud.
You can export and unsync to achieve this. The exported files would sync up to the cloud storage and then you can issue an unsync on the “root” of that exported folder. The photo export folder will then stick around in the form of a placeholder (.cloudf), which you would want to keep there. No local space would be taken once that exported folder has been unsynced.
Any individual file can be unsynced, on its own. The act of unsyncing just turns a selected file or folder into a placeholder and does not have to have any relationship to the other items in the same location.
I would suggest playing around with unsync a bit in a test folder, to get an idea of how it functions.