afsctool @1.6.4_2 crashes when compressing on High Sierra 10.13.1

[szhorvat (Szabolcs Horvát)]

Running

afsctool -c9 .

in any folder causes it to crash immediately on macOS 10.13.1 (with APFS).

It exits with the message

Segmentation fault: 11

However, if I build the version here: ​https://github.com/RJVB/afsctool myself, it seems to work fine. Perhaps an update is needed?

[RJVB (René Bertin)]

I haven't followed the original afsctool project at all since I forked my own version. Has it been maintained?

If not, then yes, some changes will be required for it to support APFS. IIRC that should be as simple as adding recognition of the filesystem; you ought to be able to figure out what to change via the issues and/or PRs associated with the cited repo.

[ryandesign (Ryan Carsten Schmidt)]

Could you attach the crash log file?

[szhorvat (Szabolcs Horvát)]

I am not experienced with crash logs. I looked in Console and found something that looks like an afsctool crashlog from yesterday. I attached it. I couldn't find the one produced by today's crashes.

Re RJVB's comment: I CC'd him because I thought that the MacPorts version of afsctool was the same as his fork (given that he is active here). The original afsctool from ​https://brkirch.wordpress.com/afsctool/ has not been updated in 7 years. There are several forks on GitHub, but with a tool that has the potential to cause data loss, I am not entirely comfortable trying versions from random people I do not know at all. This is especially true now, as Apple has switched file systems.

[RJVB (René Bertin)]

Replying to szhorvat:

Re RJVB's comment: I CC'd him because I thought that the MacPorts version of afsctool was the same as his fork (given that he is active here).

No. I once proposed my modifications as a patch to the port but that was rejected - so I just created my own fork and port (available via the github.com/RJVB/macstrop repo).

FWIW, my fork doesn't only include APFS support but also parallelised invocation and an even more thorough backup feature for those rare cases where things do go wrong (not that I ever see that happen).

The original afsctool from ​https://brkirch.wordpress.com/afsctool/ has not been updated in 7 years.

Thanks for confirming :)

[raimue (Rainer Müller)]

RJVB, as I remember it, you once proposed parallel patches for afsctool on the mailing list. I cannot find any related ticket on Trac, though. I always recommended to contact brkirch as the original author to ask if they were okay with you taking over the project. MacPorts itself does not want to host large local patches for new features or even host upstream source code in the ports tree, which is meant to provide software hosted and developed elsewhere. Since then, I have not heard anything else about updating afsctool and I was not aware you kept developing your fork.

Another instance I remember there we definitely rejected afsctool was to use it for compression in base – it is GPL-3 software.

If you were unable to get in contact with the original author, you may execute a one-sided takeover of the project and proclaim your version as the new official upstream or fork the project with a new name. Then we can discuss to provide this in MacPorts. However, nothing of this as happened as far as I am aware.

I took a look at your fork and unfortunately I see problems with it. Although the project is licensed as GPL-3+, the files ParallelProcess.{cpp,h} are marked with your copyright but state they are licensed under the ​CPOL License. This license is not approved by OSI and ​marked incompatible with GPL-3. For code you wrote yourself, you could simply relicense it. However, at least in CritSectEx.cpp and Thread.cpp you took code under CPOL and modified it. In this case, you need to seek approval from the original author to relicense this as GPL-3 or rewrite it completely from scratch. I am mentioning this here, but I can also file an issue at the GitHub project if you would prefer it over there.

[RJVB (René Bertin)]

Replying to raimue:

Since then, I have not heard anything else about updating afsctool and I was not aware you kept developing your fork.

No, I have been perfectly happy reaping the benefits of my own work and sharing it via github (where people clearly find it). I notice mine isn't the only fork that has been seeing continued development.

I do remember having tried to contact the original author of a piece of abandonware and never having had a reply. I think that was 'brkirch'.

I took a look at your fork and unfortunately I see problems with it. Although the project is licensed as GPL-3+, the files ParallelProcess.{cpp,h} are marked with your copyright but state they are licensed under the ​CPOL License.

That's most likely a simple case of copy/paste contagion. I'll just edit the modules I wrote from scratch to make them subject to no license at all. There's nothing earth-shatteringly novel or innovative in my code so I wouldn't even mind if it were reused without credit.

This license is not approved by OSI

Why would I care?

​marked incompatible with GPL-3.

I won't be making afsctool available commercially (and MacPorts wouldn't either AFAICT) and try as I might I cannot read any of the CPOL text as "you're not allowed to modified code released under this license". In fact, that'd be completely contrary to the CodeProject goals (so I'll write that off to the GPL people trying to make life difficult to any license less contagious than itself).

For code you wrote yourself, you could simply relicense it. However, at least in CritSectEx.cpp and Thread.cpp you took code under CPOL and modified it.

No, the thread class is my work entirely, and so is everything in the msemul modules. I'll have to check, but the MutexEx class I am actually using may also be my own contribution.

In this case, you need to seek approval from the original author to relicense this as GPL-3 or rewrite it completely from scratch.

Either way that's not how I read things so I'm not going to waste time reimplementing wheels unless forced to do so under tangible threat of legal consequences (and then it'd be afsctool.c itself, to get rid of the GPL3 license...)

[raimue (Rainer Müller)]

Seems like I made wrong assumptions where these files come from due the headers pointing to codeproject. I am sorry for not checking deeper, but the impression by that was that the file came from the linked project by a third-party author. Thank you for the clarification.

Open source license are not easy, so let me still answer why I thought this would be a problem. In this case, it does not matter whether your software is commercial or not. The GPL does not allow to impose stricter terms than the GPL itself does. CPOL states that you cannot "use the Work for illegal, immoral or improper purposes" (another question would be who decides what that is?). This additional restriction is not in the GPL and thus, the licenses are incompatible. Due to the viral nature of the GPL, the resulting product could not be licensed as GPL-3. Of course you can do that for your own experiments as long as you keep it to yourself, but as soon as you distribute the results (source or binary), the GPL-3 has to be applied to the whole product.

Other repositories with the same name exist on GitHub, but they are mostly just mirrors or forks that are explicitly mark unmaintained. I definitely also do not like the GPL-3 and it is sad that there is no BSD licensed alternative (or even a builtin tool in macOS to use this filesystem feature).

[raimue (Rainer Müller)]

In b015b54a47db089b3dfe90961282d3c786517b9c/macports-ports:

afsctool: Fix filesystem detection for APFS

Although still undocumented, the f_type number for APFS has changed once
again in macOS 10.13 High Sierra. Use the filesystem name by string
instead for a more robust detection.

Closes: #55214

[raimue (Rainer Müller)]

The segmentation fault was indeed caused by a format string mistake in the patch local to MacPorts. This was only triggered in case of an unknown filesystem caused by the changed f_type number.

[RJVB (René Bertin)]

Replying to raimue:

The GPL does not allow to impose stricter terms than the GPL itself does. CPOL states that you cannot "use the Work for illegal, immoral or improper purposes" (another question would be who decides what that is?).

The latter two have no legal basis that I know of, and as to illegal uses ... I don't think the GPL can *allow* that. Illegal things are by forbidden by definition, so mentioning them explicitly shouldn't make a license any stricter. A bit like adding "this software can only be used by carbon-based humans" instead of "humans"

Anyway, I have a question about APFS compatibility (the main topic here). afsctool uses 2 data types (HFSPlusAttrKey and HFSPlusCatalogFile); do we know if these are valid for files on APFS too? I guess the former might, the latter maybe not - and I haven't found anything online to answer this.