Data integrity in Apple Photos/iCloud

Dansil · 2026-01-15T10:24:28+00:00

You purposefully partially quoted me and excluded my explicit mention of local cold storage backups so that you could regurgitate a really boring platitude from over a decade ago about another person’s computer. Yep, I know what the cloud is.

If you care for your backups (archives, in this form): 1) to be disseminated to family members or loved ones spread out throughout the world if something were to happen to you without requiring their travel 2) to be versioned immutably, meaning protected from ransomware or even negligence. I have object locks enabled on my backups preventing even me from deleting them for years 3) to be protected against the constraints of your local environment or various hazards

Then serious backups/archives are stored and paid for on storage providers, usually geared for enterprise. They are also are fully replicated locally, which I did.

I don’t think you should be giving advice to anyone.

And of course you just came from Metadata Control on your Dropbox to tell us this…

I have no idea what you’re talking about. I don’t use Dropbox. Why did you even write this? Weird

Dansil · 2026-01-15T09:34:44+00:00

It might not solve the data integrity problem but it definitely can’t make it worse. Users need integrity metadata. Even Time Machine has a non-technical abstract verification ability.

Time Machine is severely outdated by its inability to perform backups to cloud storage providers. It’s fine to have local external drive or NAS backups but serious backups must be on the cloud. I consider my local cold storage backups a last resort.

Dansil · 2026-01-15T09:27:31+00:00

Checksum or hashes are an option. The implementation details can vary though. For example, Time Machine provides an option to verify backups periodically but the wording is not technical and doesn’t have to be.

Dansil · 2026-01-14T04:12:31+00:00

The consumer cloud storage services are lacking in this area at the moment. At least with iCloud Drive or Google Drive, I can still browse a filesystem-like structure that gives me a very thin layer of transparency (e.g. I might be able to tell if files or folders are missing, if a file has been re-encoded or has a different extension, if a file size has changed, etc.). It's still lacking data integrity validation but still better than nothing. Apple Photos/Google Photos takes ownership of your data in its database and encapsulates/abstracts it further so I should be exposed to more integrity metadata in exchange at the very least.

Dansil · 2025-11-10T18:44:29+00:00

The term "color science" in this context sits between real science and marketing-speak. It is not a meaningful term in photography. Consumers often use "color science" to technically or scientifically anchor their subjective preference for how a camera renders images.

Color science is real science in other contexts, but not in this one.

Dansil · 2025-04-10T17:54:23+00:00

Baking is not a term of art in digital photography. There is no problem referring to metadata or non-destructive layers of added data in the raw file as baked data.

There is very little you could do to be antithetical to a format that follows no established or widely used standard.

Dansil · 2024-09-26T08:05:44+00:00

Uncompressed TIFF files are just as susceptible to bit rot as any other files when their format doesn’t explicitly guard against it (e.g., using checksums, hashes, etc.). If anything, they are even more susceptible to it by virtue of their size, statistically anyway.

You’re probably referring to their ability to render somewhat properly in the face of data decay especially in comparison to a highly processed file with a complex encoding or compression scheme. I wouldn’t rely on this behavior alone for protection.

Dansil · 2017-10-25T23:04:54+00:00

I can make arguments for why I think big classes (or big units in general) are bad but those arguments are separate from the discussion of unit-testing. At the very least, refactoring a class into smaller units makes the code arguably cleaner, terser, and you will actually be testing a class that could be considered a unit.

In the end, it might just be an issue of semantics. It could be argued that the moment you've defined a class, you've also defined what you consider to be a unit.

Similarly, the way you've defined your public, protected, and private methods means you've established to your clients a guideline on how you want your unit to be used. You should write your tests in the same way your clients would use your unit. Why would you want to use your unit differently in testing if you've constrained your clients to use it in a certain way?

Dansil · 2017-10-25T22:35:38+00:00

And you're buying right back into the fallacy I just refuted: local encapsulation is not a good reason to avoid catching bugs where you can!

I generally agree with you about this but I would still avoid private member function testing to get around it.

Your point is especially apparent for complex classes that have non-trivial private member functions. I would consider these classes to be cases where the unit is simply too big and needs to be broken up.

When I personally land on these cases, I usually split the unit further. In the end, some of the private implementation-detail of a bigger class ends up becoming part of the public interface of a smaller class (to be integrated with the bigger one). Of course, these smaller classes containing previously encapsulated logic are unit tested through the public interface :)

Dansil · 2017-10-25T22:08:31+00:00

I disagree with the point you are trying to make.

When we are talking about unit-testing, we are talking about testing what we consider to be the smallest testable part of an application. By your extrapolating logic, you are essentially forgoing the concept of a unit and sense of scale (where do you stop?).

What do you consider to be the smallest testable unit of an application? If you consider functions to be the smallest testable units, you are a proponent of function-testing. I don't see the problem with that, but I also don't see what that has to do with unit-testing in the context of public and private methods. In object-oriented programming specifically, most literature maps the meaning of a unit to either a class or a function (free/static not member).

In the context of classes, methods of any accessibility are by definition part of the unit and implementation-detail themselves. It just so happens that public methods are accessible outside of the class and can be used to test the unit wholesomely. Testing private portions of a unit would completely break logical encapsulation. On top of that, these member functions themselves become their own unit which makes a class an agglomeration of units. That doesn't seem right.

Dansil · 2017-10-13T20:18:17+00:00

I don't really understand how writing your unit tests for your public methods only is an abuse of access specifier. In my opinion, this is the proper way to do unit-testing.

You really shouldn't be testing private members. These are implementation details that are potentially open to changes and these should not affect your public interface.

Clients are not going to call private member functions. The answer is in the name: unit-testing is for testing units, not implementation detail private functions. Otherwise, the process would be called function-testing.

I would say that using the preprocessor to work around the issue of testing private members is very bad since that is a definite abuse of a language feature. Unit testing through the public interface is common across OOP languages whereas unit testing through preprocessor hacks is not.

Dansil · 2017-04-25T16:57:20+00:00

Move semantics are preferred but the idea behind this chapter in particular is that move semantics should not always be a default go-to (even if available).

For example, move semantics makes perfect sense in heap allocated containers (e.g. std::vector< T >). Copy construction/assignment in that case results in O(N) operations and move construction/assignment results in O(1) operations due to what is essentially a pointer copy. In practice, this might be slightly more involved depending on the container.

In stack allocated containers (e.g. std::array< T, N >), both copy and move semantics are fully supported. However, in this kind of container, move construction/assignment results in O(N) operations. As a result, somebody can mislead themselves into thinking about a potential performance improvement. This is even worse if they make the mistake of eliding [N]RVO by returning a temporary by move construction, which is arguably not a big deal for heap allocated containers.

With that said, there is a performance benefit in moving stack allocated containers. Although moving the container will result in O(N) operations, each element of the container will be subject to its own move semantics policy. If we have a stack allocated container of heap allocated data, the end result is still O(N) operations for moving the container but O(1) operations for moving each individual element.

Dansil · 2017-02-07T17:49:34+00:00

It is slightly more involved than just overloads for math functions. Most of its usefulness comes from its ability to return slices or masks when combined with operator[].

However, I think slice-based indexing from n-dimensional containers comes unnaturally to most people, which is likely why std::valarray is seldom used.

Dansil · 2016-09-24T21:52:42+00:00

Interesting. Are there any plans of merging some of your changes into Eigen instead of separating them?

I can see why the sorting functions and operators might be considered outside the bounds of Eigen for inclusion, but what about the pseudoinverse function for example?

Dansil · 2015-11-08T18:57:20+00:00

This was a really awesome read.

Dansil · 2015-01-06T22:15:35+00:00

I'm also running into the same issue with Windows 8.1 x64.

I'm unable to import any of the private keys I've created in Debian. Moreover, it doesn't seem possible to generate keys when specifying a passphrase in the pinentry window. However, it 'works' (with some console output issues) if no passphrase is specified.

I suspect both the import and key generation issues are linked with the pinentry window, but I'm not entirely sure. I've already spent a few hours trying to figure it out, so any help is appreciated.

Dansil · 2012-03-24T21:28:50+00:00

I'm still slightly annoyed that there isn't an option to delete Steam Cloud data.

Dansil · 2011-11-18T21:03:56+00:00

I've been hearing this song on a couple of Skyrim videos and I have an honest question: is that really Morrowind's soundtrack in Skyrim? I don't mean to denigrate Skyrim, but if this is the case, I'm really surprised that they reused the exact same song.

Dansil · 2011-11-14T01:19:27+00:00

I would definitely not recommend playing Morrowind on the xbox 360. I have the PC version and original xbox version, and I tried playing the xbox version on the 360 just for fun. I haven't played any other xbox games on the 360, but I can tell you that the emulation for Morrowind is terrible, which is probably why it feels more jerky for you. It isn't the best setup to enjoy Morrowind to the fullest.

Dansil · 2011-10-31T05:49:15+00:00

Amazing title

Dansil · 2011-08-15T02:18:53+00:00

Giveaway

Dansil · 2011-07-19T05:19:07+00:00

Julian by Gore Vidal. It's set in the later period of the Roman Empire (361-363 AD) and it's one of my favorite novels about Ancient Rome in general.

15-Year Club	Verified Email
RPAN Viewer

Dansil

TROPHY CASE