|
|
|
|
|
by dreamcompiler
3194 days ago
|
|
> 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. |
|
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.