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.
Ente
Ente is a service that provides a fully open source, end-to-end encrypted platform for you to store your data in the cloud without needing to trust the service provider. On top of this platform, we have built two apps so far: Ente Photos (an alternative to Apple and Google Photos) and Ente Auth (a 2FA alternative to the deprecated Authy).
This monorepo contains all our source code - the client apps (iOS / Android / F-Droid / Web / Linux / macOS / Windows) for both the products (and more planned future ones!), and the server that powers them.
Our source code and cryptography have been externally audited by Cure53 (a German cybersecurity firm, arguably the world's best), Symbolic Software (French cryptography experts) and Fallible (an Indian penetration testing firm).
Learn more at ente.io.
Ente Photos
Our flagship product. 3x data replication. Face detection. Semantic search. Private sharing. Collaborative albums. Family plans. Easy import, easier export. Background uploads. The list goes on. And of course, all of this, while being fully end-to-end encrypted across platforms.
Ente Photos is a paid service, but we offer 5GB of free storage. You can also clone this repository and choose to self-host.
Ente Auth
Our labour of love. Two years ago, while building Ente Photos, we realized that there was no open source end-to-end encrypted authenticator app. We already had the building blocks, so we built one.
Ente Auth is free, and will remain free forever. If you like the service and want to give back, please check out Ente Photos or spread the word.
Contributing
Want to get aboard the Ente hype train? Welcome along! Don't hesitate if you're not a developer, there are many other important ways in which you can contribute.
Support
We are never more than an email away. For the various ways to ask for help, please see our support guide.
Community
Please visit our community page for all the ways to connect with the community.
Security
If you believe you have found a security vulnerability, please responsibly disclose it by emailing security@ente.io or using this link instead of opening a public issue. We will investigate all legitimate reports. To know more, please see our security policy.



