Windows: duplicate files in separate folders

[kangruixiang]

Hi, I'm using version v3.4.3 on Windows and using the shortcut option:

My understanding is that with this option all of the files will be moved to one folder with the albums in separate folders as links. But that doesn't seem to be the case.

In some cases, the files are still in separate folders. Example below, where there's folder for 2013/7 album and then separate folders under "ALL PHOTOS," both of which have original files.

Here's an example where some of the files are now links in the album folder, but then you have a few files that are duplicate under both album folder and "ALL PHOTOS" folder. I have one of the duplicate files highlighted here:

In other cases it seems to work. See below where the folder for album on the left have links instead:

It just seemed to be so random which version of those three I'll get.

[TheLastGimbus]

Oh... divide by dates also applies to albums... didn't know :joy:

Very nice issue by the way - screenshots of everything, etc - thanks :pray:

There is a fallback that does exactly what you are seeing:

https://github.com/TheLastGimbus/GooglePhotosTakeoutHelper/blob/1c17c70ed8f243d6a38df5283ba094f82fc8f67f/lib/moving.dart#L143-L151

Did you maybe see this error message while running - if so, we know the problem then

But, problem is still there... i have no idea why powershell didn't create those shortcuts... they seem to have normal nice names, no spaces or special characters........... maybe the folder has space in it's name??

Idk, but honestly this isn't especially stable feature of gpth :confused: - Windoza seeeems to support actual symlinks, we may migrate to that later: https://github.com/TheLastGimbus/GooglePhotosTakeoutHelper/issues/248#issuecomment-1740759065

[kangruixiang]

So I didn't see any error messages. Everything seemed to go smoothly until you go back to double check.

So I just ended up doing one big folder with years and months and json files. That worked ok but also didn't move all of the files in one go. I had to run the program like 4-5 times until everything got moved.

If I get a chance I'll go back and rename some of the folders to see if removing the space would help. Thanks for the reply.

[TheLastGimbus]

That worked ok but also didn't move all of the files in one go

Oh no. No no no no don't do this unless you're 100000% sure that's what happening

Please read https://github.com/TheLastGimbus/GooglePhotosTakeoutHelper/issues/253#issuecomment-1754558791 , and if you're still sure that gpth didn't move all of your photos we're calling an emergency meeting cause that would mean gpth is loosing people's photos :grimacing:

[nk111]

I have observed the same behavior. The majority of my albums still contained original files after running GPTH with the same options like the OP. Some of these original files were even found in multiple albums. Some of them were NOT in the ALL_PHOTOS folder! So I would argue, yes, GPTH does not back up ALL photos in ALL_PHOTOS and there is a risk of losing files.

I downloaded the sources and re-exported everything to debug a little. Will report back.

[nk111]

One big problem seems to be that there are several albums (at least in my case) which contain files that are NOT in the year folders. For instance I've found three album folders with identical images that are not contained in any "photos from..." folder. In these cases the files end up in the big sorted media collection with no file in the group having a null key. That means that every copy will be copied physically and not as a shortcut since there is no mainfile. This should be handled by creating a mainfile first in these cases imho.

Here is an example of such a file:

[TheLastGimbus]

which contain files that are NOT in the year folders

well, thank you google - again :)

hm, this might actually be because you, for example, had them hidden in main timeline (by putting them in archive?) and putting them into albums at the same time?

This should be handled by creating a mainfile first in these cases imho

Yeah, absolutely. This is delicate, but i will try to make a fallback behavior for that :+1: