[eps]

And this is how you do SEO-oriented content marketing, kids.

Rather light on the substance, few select links (with at least one pointing out) and lots and lots of precisous keywords.

--

Besides, the fact that a _file_ backup tool might need a near complete rewrite with a change of a file system should raise some eyebrows. It might be understandable for an imaging backup or if it was working directly with raw file system, but this one doesn't.

[feelix]

I finished up the APFS compatible version of the software way quicker than I thought I would, and was so happy and energized that as part of my release I whipped up a quick blog post about the experience.

Indeed it's pretty light on content, it's more just a nod to Apple for making this a painless process rather than an excruciating one, as well as an early relay of the experience to others who are going to upgrade who may be harboring some concerns like I was.

The marketing for this site sucks, the software has been around since 2011 and it has nowhere near the marketshare of its competitors because it sucks. If I were really some SEO genius (and you'll see the google rankings are terrible), then this would not be the case. In short, I wish I was the evil genius that you claim, but I'm not. I'm just a dev sharing his experience with the filesystem.

In regards to it not implementing the file copying tool directly - that is covered in the article. The fact that the file copying tool was compiled in 2015 and still works flawlessly is the whole premise of the article stating that it's impressive. And it being a _file_ copying tool is the part that _makes_ it impressive. You seem to have no idea how complex the metadata, built up over 30 years without a rewrite, on HFS+ is. Take a look at BackupBouncer and the associated blog posts to get an idea of the situation. It's pretty crazy.

[dreamcompiler]

> Besides, the fact that a _file_ backup tool might need a near complete rewrite with a change of a file system should raise some eyebrows.

It appears you've never written file backup software for MacOS. I have, and it's anything but trivial to get all the edge cases right. There are half a dozen different schemes for metadata and you have to handle all of them. There are packages which are really directories. ACLs. Two different kinds of softlinks, plus hardlinks. Finder attributes. Hidden files and caches that usually don't matter, but sometimes do. Creation dates, which don't exist on [older versions of] linux. And legacy cruft like resource forks and file types, which some users still depend on. Spotlight comments (nee Finder comments). Tags. Special locks added by Time Machine. Weird new locks that even root can't penetrate. (You have to fail gracefully on those, as the author points out.)

It's a nightmare. Go write a complete file-level backup system or a transparent VM file-mirroring solution for HFS+ and get back to me. In the meantime, you'll just have to trust the original author when he says that Apple's seamless transition to APFS is astonishing.

[eps]

Incidentally, I did work on a backup program for Windows and Unix-ish OSes some years ago. There are indeed locked files, there are hardlinks, symlinks, junctions and other types of reparse points that will give HFS+ a run for its money, there are alternate streams, DACLs, SACLs, there is a monstrosity called volume shadow copying, there is a lack of support for created times on some file systems, times that are supported are truncated differently, some file names are not supported here, but supported there, etc. Lots and lots of cruft accumulated over past decades.

But it's not a nightmare. It's just a very large pile of mostly trivial stuff.

Also none of this should require a "complete rewrite" if you are to add support for yet another file system. Saying something like this means that either existing program is a bowl of spaghetti code _or_ that someone is being coy and exaggerates implied difficulties. Are you going to argue with that? Because that was the point you were commenting on.

[dreamcompiler]

I would have expected two things with the transition to APFS:

--Certain edge cases of HFS+ were no longer supported or would now be supported differently.

--The various special-case file-manipulation APIs in MacOS would have changed.

Both the above tend to happen to some extent with every major rev of MacOS and even some minor revs, and they necessitate substantial code changes. The fact that the old code still "just works" with the APFS change I find surprising.

[feelix]

I was initially planning on a complete rewrite in order to start supporting snapshots in a different way (by using the ones saved by APFS). Going into that was outside the scope of the article.

[Confiks]

> And this is how you do SEO-oriented content marketing, kids.

And this in turn, kids, is how you assume bad faith without any reservation or doubt.

[yjftsjthsd-h]

Having watched the news for a while, primarily on HN and Slashdot, I've seen enough tracking, leaks, sell-outs, adware incidents, dirty marketing, astroturf campaigns, compromised software, etc. to not expect some degree of bad faith. Perhaps not this time, but it is totally reasonable to question everything.

[eps]

Who said anything about this being written in bad faith?

It's a really well executed example of content marketing. Whether it was intentional is a separate question, but the post is really quite shallow in technical terms and it exagerrates things here and there, so - yeah, it does look like something written primarily for promo reasons.

[_ix]

Sure. There's nothing wrong with promotional material, nor is there anything wrong with calling a spade a spade.

To be fair, though, your original comment did come across as negative — was it supposed to?

[coldtea]

>Rather light on the substance, few select links (with at least one pointing out) and lots and lots of precisous keywords.

And yet I've learned more from the post than from this comment.

They have like 6 posts on their blog over several years. Hardly the SEO spinsters one would imagine.