Maybe rclone should be dealing with duplicates in the drive interface… Google drive objects (and photo objects) have a unique ID so maybe rclone should stick it on the end if it finds a duplicate… So
That would break syncing though if it stuck all of them on the end, so maybe it should choose the oldest to not have the extension and put extensions on all the others, so
Something like this would be good. I was going to suggest a flag to download duplicates because of the photos/drive interface but didn’t bring it up. Because photos is ‘supposed to’ have duplicates, I found that I couldn’t download them because rclone would just complain about them. It would list them, of course, but since a single destination can’t deal with the duplicates (linux FS) that it would just politely tell me there was some.
It would be nice to have a flag to rename them in much the same way as ‘dedupe’ does. I could pass the flag of ‘skip|first|newest|oldest|rename’ and it would do that operation on the copy. In my use case, I didn’t want to dedupe, I wanted to download specific slices of a ‘duplicate’. I do like the idea in addition (as part of rename) to use either the hash or the ID though.
Its good that they provide a method to transfer files from drive to make them available in photos though. But the part that will really hurt is if they do not provide a means to extract them from photos since that is where their photos app syncs to. We shall see.
Also, those links aren't even correct....
"Thus, you could access the files uploaded to Google Photos and add new ones via Drive. You won't be able to do that anymore, though. "
You couldn't do that. Adding files via drive never appeared in photos like that.
I hope the photo app allows us to backup directly to drive.
Yes indeed. At the moment, if you upload Photos or Videos on Google Drive you need to enable the option that Google Photos uses uploaded files from Google Drive. Because you uploaded it to Google Drive directly they are in original quality so they count towards you storage.
They should at least let us set Google Photos to create in Google the Google Photos folder. This way we can at least build up a folder structure if we want to share specific images instead of creating an album or sort of.
Check if you turned on Upload newly added photos and videos to Google Photos.
What you need to know
If you use Backup & Sync to upload photos and videos to Drive and Photos, it will upload a copy to each service, but it will not take up duplicate storage.
If you remove a photo or video from your computer it won't be removed from Google Photos.
If you remove a photo or video from Google Photos it won't be removed from your computer.
This says you can select either service or both. That would be a huge improvement. I'd like to be able to backup directly to both....
Yeah. If this works no problems should occur. Well one thing is annoying. You need to use the Backup & Sync. I hope it works also for API. Probably not. If the API can do it. This would be great.
Means uploading with rclone would make no sense if you want you photos on GPhotos and GDrive.
The other question which I'm asking myself. If I'm sharing a photo with someone as a partner, does it still appear in Google Drive?
Hmm. Regarding API. When i'm not wrong you still can't upload photos in "high quality". This holds it a bit back i guess. Hopefully Google is adding this.
This is no improvement, it's been like that from day 0 as Backup&Sync was introduced both to upload to Drive and to Photos (and to replace the standalone desktop uploader). The only problem is that Backup&Sync is HORRIBLE:
it won't do a real backup, it can only sync both ways (dangerous)
it would even without any changes pollute the "originals" with some temporary files, which it forgets that it made then next time it starts it will upload and then delete and then download
it won't accept read-only folders if you try to block it in any way (like mounting a remote R/O share).
It is really annoying and scary to see it doing "updating" and "downloading" shit in your Pics2005 folder.
if you have many pictures (which you might very well have if you take lots of them since the early days digital photography) it takes a long, LONG time to start counting and crunching, you might need to let it overnight to just start transferring something
this might happen also if you have lots of files in your account (drive), unrelated to what you want to backup
I'm aware that tool sucks. I'm hoping they give the functionality to backup via Android directly to drive rather than indirectly. Seems to have been implied but who knows. We'll find out soon! I've considered stopping using the "photos" app to backup pictures entirely and instead use rclone with "automate for Android" to roll my own solution. The app would be easier though if I can get them from photos to drive and then back to another account's photos.
The feature to import from drive to photos will also help in my use case. I populate a gsuite account with our entire families worth of pictures and want them in Google photos. As long as it's done well (not holding my breath) it would be nice to just transfer files from drive to photos.
Yes, rolling your own rclone based solution to upload to drive (even on the phone) is the way to go. Also their Photos app is a disaster, I mean it's taking 5.6GB on the phone for whatever db/cache it has (not related to ANY pictures I manage locally on the phone). It kind of works, even if the feedback it gives is minimal (I wouldn't trust it in any case to remove my local pics it uploaded to Photos to save space...).
Given that you can't easily access Google Photos directly to compare what's there with what's on the phone once you are above a few hundred pictures (like realistically everybody is nowadays) you won't be able to tell if it loses pictures here and there. Sure, you'll notice if it stopped uploading anything since last month (for example) but that's harder to happen, the app gets restarted every now and then for many reasons like killed for power saving, flushed out of memory, updates.
.
Preferences.