I have a local fileshare that I did a 'drag and drop' onto Google Drive (300GB took 3 days)... folder names, file names, everything the same. To not have to keep the two in sync manually, I pointed filesync to the local fileshare and then to the google drive folder. FileSync is reuploading every single file in the same folders. 300GB - which in effect, doubles my needed space as each file it deletes goes into a trash folder and still counts against my storage quota.
This combined with the 15 second timeout is creating a VERY disagreeable experience with FileSync.
So, if I can get through all the heartache of this 'first time'... does anyone know if FileSync is going to attempt to recreate all 300GB each time? I'm only 50% of the way through the upload (9 days now), and if this isn't going to work, I'd like to give up now.
Thanks!
FileSync copying over all files AGAIN
- Posts: 17
- Joined: 27 Jul 2020
- Posts: 1037
- Joined: 8 May 2006
What sync settings are you using?
If Date & Time, are the dates/times the same, between your source & the original uploaded files?
Are the dates/times the same, between your source & the FFS uploaded files?
Are the relative directory trees the same between your original upload & the what you are now using in FFS?
If Date & Time, are the dates/times the same, between your source & the original uploaded files?
Are the dates/times the same, between your source & the FFS uploaded files?
Are the relative directory trees the same between your original upload & the what you are now using in FFS?
- Posts: 17
- Joined: 27 Jul 2020
All date/times are the same (as far as I can tell) - these are all the exact same files, same directory structure, same names, etc. I am sure there should have been a small handful of files that would have needed to be synced... 4 new files, 1 deleted file, 1 moved file. I am mirroring my local share to my google backup folder. As I look at the 150GB it has already 'sync'd' - it is not changing anything. It is simply deleting each file and uploading it new. It says it is Updating the file, but the file is deleted (in Trash) and the files it uploaded are identical (and in the same directory structure). I can look for something specific if you like?What sync settings are you using?
If Date & Time, are the dates/times the same, between your source & the original uploaded files?
Are the dates/times the same, between your source & the FFS uploaded files?
Are the relative directory trees the same between your original upload & the what you are now using in FFS? therube, 28 Jul 2020, 16:49
I have another backup tool that is making backups of the same directory structures (although encrypted) - and it is able to upload only changes (and not fail with every 15 second delay). This is used as my disaster recovery backup/restore/version. What I want to use FileSync for is to create a viewable duplicate on google drive of these specific folders and I just don't want to manage the synchronization manually. Things seemed to work fine locally - but only if FileSync creates the initial mirror. If I do my own copies - drag and drop the top most directories - FileSync doesn't seem to be able to deal with it.
- Posts: 33
- Joined: 14 Jul 2020
What is the date shown in FFS? Anything else doesn´t matter for FFS!
1 or 2 hour differenes can be ignored through a compare setting.
A screenshot of the compare could help.
All in all, if you came from an clean/empty cloud you should have uploaded everything through FFS and not manually to create a proper 'sync.ffs_db' necessary to detect changes.
Yes I saw FFS deleting and creating every file new, in case the time stamps just differs for seconds or one letter, if not a proper entry in the 'sync.ffs_db' exists for a file or this database is not created yet.
Also before running the sync FFS has told you which files it want´s to update/change. Also the amount of GB.
Any misbehaviour through the way of cloud communication FFS does I don´t know.
1 or 2 hour differenes can be ignored through a compare setting.
A screenshot of the compare could help.
All in all, if you came from an clean/empty cloud you should have uploaded everything through FFS and not manually to create a proper 'sync.ffs_db' necessary to detect changes.
Yes I saw FFS deleting and creating every file new, in case the time stamps just differs for seconds or one letter, if not a proper entry in the 'sync.ffs_db' exists for a file or this database is not created yet.
Also before running the sync FFS has told you which files it want´s to update/change. Also the amount of GB.
Any misbehaviour through the way of cloud communication FFS does I don´t know.
- Posts: 17
- Joined: 27 Jul 2020
Thanks! I'll have to look then next time I have to restart the app... also another anomaly I can't pin down... my normal rock-steady iMac (reboot every 6 months), now has to reboot every other day when I run FFS... eventually Finder is unresponsive, then finally BSOD (black for MacOS)... but I can't pin that down to be certain about blame... just observables.
I'm hoping that once FFS has copied everything to the cloud it will be able to 'behave' and only migrate changes from my local share. I was hoping there was some setting I was overlooking like 'if I (FFS) didn't copy it over, don't trust it - even though it's there'... that I could uncheck :)
And yes, it tells me up-front (after the compare) what it wants to copy and how big it is (GB). Initially I thought it was because it wanted to set up the directory structure slightly differently - but when I saw that it was deleting every single item and then replacing it with an exact duplicate - it felt like something just wasn't right.
Thanks for the input!
Russ
I'm hoping that once FFS has copied everything to the cloud it will be able to 'behave' and only migrate changes from my local share. I was hoping there was some setting I was overlooking like 'if I (FFS) didn't copy it over, don't trust it - even though it's there'... that I could uncheck :)
And yes, it tells me up-front (after the compare) what it wants to copy and how big it is (GB). Initially I thought it was because it wanted to set up the directory structure slightly differently - but when I saw that it was deleting every single item and then replacing it with an exact duplicate - it felt like something just wasn't right.
Thanks for the input!
Russ
- Posts: 33
- Joined: 14 Jul 2020
Okay.
You could maybe choose compare file size instead of date. By date is not always the best. Example, my mp3/Video-Tagging software is set to not changeing the dates after editing. Nor does the size change beacuse of the fix header-size, thus for my music-archive I have to use by bit.
It might help to save bin space on google when you tell FFS to permanently delete in the synchronisation settings (green gear) instead of moving it to bin.
You could maybe choose compare file size instead of date. By date is not always the best. Example, my mp3/Video-Tagging software is set to not changeing the dates after editing. Nor does the size change beacuse of the fix header-size, thus for my music-archive I have to use by bit.
It might help to save bin space on google when you tell FFS to permanently delete in the synchronisation settings (green gear) instead of moving it to bin.
- Posts: 17
- Joined: 27 Jul 2020
Good tip on the 'permanently delete' - thanks!
- Posts: 17
- Joined: 27 Jul 2020
Good news. After FFS copied all the files over to gDrive again - subsequent runs of the job only process updates as expected. For some reason, it is erroring on a few files - it says it's trying to write a file but it already exists... it's true the file is there, not sure why it's trying to write it again (or why it can't when it was able to for all others) - but perhaps there's a lock on the file somehow. No biggie. Thanks for your help!
-
- Posts: 4056
- Joined: 11 Jun 2019
For those, you can usually delete that file from the destination and let it sync again. It could be permissions, attributes, many things
