TheLastGimbus / GooglePhotosTakeoutHelper

Script that organizes the Google Takeout archive into one big chronological folder
https://aur.archlinux.org/packages/gpth-bin
Apache License 2.0
3.88k stars 191 forks source link

Don't reset original created time for un-guessed files. #128

Closed MrModest closed 1 year ago

MrModest commented 1 year ago

Hi! First, thanks for the helpful utility. Thanks for your time and patience.

And a small comment here. Could you please don't reset created dates for files that the script didn't manage to guess? I see that these files have correctly created dates in the original folder, but their dates changed to current after the script. I would be able to sort it manually after the script, but now it's harder to do this.

TheLastGimbus commented 1 year ago

Huh... i don't know why this happens for you... i used shutil.copy2/move, it shouldn't modify dates 🤔

MrModest commented 1 year ago

I don't know how, but I found photos with certain dates from the Takeout folder in my 2022/11 folder with created date as the day of the script running. 🤔

I used --guess-timestamp-from-filename flag, and in your README I also see

If you leave this off, or if no date can be guessed from the filename, those photos will be assigned the timestamp of when the script was run.

TheLastGimbus commented 1 year ago

Oh... yeah, completely forgot about this :laughing:

hmmmmm, honestly, i have no idea why... maybe @hheimbuerger does? He made the PR with this...

hheimbuerger commented 1 year ago

@MrModest I'm not quite sure I'm following, what your issue is. Are you sure this script has ever set the creation time the way you expect it? Which platform are you on?

--guess-timestamp-from-filename does not actually modify the code that sets the file metadata in any way. It only adds one more way a photo date could be determined -- as a kind of last resort to avoid it being set to 'now'.

I believe this is the function that sets the file dates. On Linux, this uses os.utime, which does not even try to set any creation date. (Does that even exist on common Linux filesystems?). On Windows, it appears to use some external library.

However, looking at my own Google Takeout-exported photos (which were run before the introduction and therefore without the --guess-timestamp-from-filename option, I believe) all have only the modification date set to the date the photo was taken. The creation dates appear to be the date the script was run for all photos.
But I don't have a Google Takeout export anymore to test.

In short: I suspect that at least on Windows, it resets the creation date on all photos that it touches. Maybe that's why when they couldn't be identified by the script, they kept their old date (which I believe is what you're saying). But then again, if you don't want that, just don't run the script in the first place. ;)

TheLastGimbus commented 1 year ago

Hi there!

v3 now does not reset this date, and has way better perdiction of dates anyway (because, by the way, --guess-from-name is the default now :tada:)

If you use --divide-to-dates, unknown ones will be put in "date-unknown" folder :+1: