Closed MrModest closed 1 year ago
Huh... i don't know why this happens for you... i used shutil.copy2/move
, it shouldn't modify dates 🤔
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.
Oh... yeah, completely forgot about this :laughing:
hmmmmm, honestly, i have no idea why... maybe @hheimbuerger does? He made the PR with this...
@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. ;)
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:
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.