In recent Google Takeout archives, the metadata JSON files are named
"${original_filename}.supplemental-metadata.json" instead of
"${original_filename}.json", as before.
I refactored the previous code so that `getMetadataJSONMapKeyForJSON()`
only removes the ".json" suffix from the metadata filename and does not
make any other changes. All of the filename munging is now done to the
name of the media file. That was the only way I could make the process
deterministic. As far as I can figure out, there's no deterministic way
of deriving the media filename from the metadata filename -- it's only
deterministic going from the media filename to the metadata filename.
These new names are still subject to the 46-character clipping limit,
with some specific rules about how the filename is clipped:
- The ".json" suffix is never clipped, only the ".supplemental-metadata"
portion is.
- If the original filename is longer than 46 characters, then the
".supplemental-metadata" suffix gets completely removed during the
clipping, along with a portion of the original filename (as before).
- The numbered suffix (if present) is also never clipped. It is however
added at the end of the clipped ".supplemental-metadata" portion,
instead of after the original filename. E.g. "IMG_1234(1).jpg" would
previously use a metadata filename of "IMG_1234.jpg(1).json". Now it
uses a metadata filename of
"IMG_1234.jpg.supplemental-metadata(1).json". But if the filename is
too long, it gets turned into something like
"IMG_1234.jpg.suppl(1).json".
- Worth noting is that if the original filename is 45 characters long,
then everything except for the "." from ".supplemental-metadata" will
get clipped. So the metadata file ends up with a filename like
"filename_that_is_45_chars_long.jpg..json".
I added a bunch of additional test cases in `upload.test.ts` based on
actual filenames I have in my Google Photos Takeout archives. The new
code passes all of the new test cases, as well as the original ones.
Fixes#4953
In recent Google Takeout archives, the metadata JSON files are named
"${original_filename}.supplemental-metadata.json" instead of
"${original_filename}.json", as before.
I refactored the previous code so that `getMetadataJSONMapKeyForJSON()`
only removes the ".json" suffix from the metadata filename and does not
make any other changes. All of the filename munging is now done to the
name of the media file. That was the only way I could make the process
deterministic. As far as I can figure out, there's no deterministic way
of deriving the media filename from the metadata filename -- it's only
deterministic going from the media filename to the metadata filename.
These new names are still subject to the 46-character clipping limit,
with some specific rules about how the filename is clipped:
- The ".json" suffix is never clipped, only the ".supplemental-metadata"
portion is.
- If the original filename is longer than 46 characters, then the
".supplemental-metadata" suffix gets completely removed during the
clipping, along with a portion of the original filename (as before).
- The numbered suffix (if present) is also never clipped. It is however
added at the end of the clipped ".supplemental-metadata" portion,
instead of after the original filename. E.g. "IMG_1234(1).jpg" would
previously use a metadata filename of "IMG_1234.jpg(1).json". Now it
uses a metadata filename of
"IMG_1234.jpg.supplemental-metadata(1).json". But if the filename is
too long, it gets turned into something like
"IMG_1234.jpg.suppl(1).json".
- Worth noting is that if the original filename is 45 characters long,
then everything except for the "." from ".supplemental-metadata" will
get clipped. So the metadata file ends up with a filename like
"filename_that_is_45_chars_long.jpg..json".
I added a bunch of additional test cases in `upload.test.ts` based on
actual filenames I have in my Google Photos Takeout archives. The new
code passes all of the new test cases, as well as the original ones.
Didn't want to prefix with "--ente" since these are not "global" vars, they're
only for a small scope, using the mechanism that Pigment CSS is recommending
that we follow to introduce dynamism with static styling.
"et" could mean "ente" (but shorter), or "ente temp", or whatever you wish for
it to mean really.
