Port RJVB's patches to 0.8.2

[rdmark]

A patchset for stability and fuse functionality was contributed for the baseline 0.8.1 codebase:

https://sourceforge.net/p/afpfs-ng/patches/4/

These patches no longer apply cleanly on 0.8.2 code, so this ticket is for tracking the porting effort.

[rdmark]

Attaching the patches. Omitting "offeset.diff" because I believe this was already addressed in 0.8.2

afpfs-ng-0.8.1-pointer.patch
bump_fuse_use_version.patch
return-a-value.patch
RJVBs-patches-2.patch
RJVBs-patches-askpass+fuse_options.patch
RJVBs-patches-subtype+fsname.patch
RJVBs-patches.patch

[rdmark]

@RJVB Thanks for contributing the above almost a decade ago. I always say, better late than never. ;)

[RJVB]

:)

[rdmark]

afpfs-ng-0.8.1-pointer.patch

Already in 0.8.2

[rdmark]

bump_fuse_use_version.patch

1180ca0

[rdmark]

return-a-value.patch

Already in 0.8.2

[rdmark]

RJVBs-patches.patch

e5748dd

RJVBs-patches-2.patch

69fd9db

[rdmark]

RJVBs-patches-askpass+fuse_options.patch
RJVBs-patches-subtype+fsname.patch

These patches introduce asprintf() which I believe is a GNU extension. I want to keep support for non-GNU OSes like *BSD and macOS. Needs some more work before adopting.

[RJVB]

These patches introduce `asprintf()` which I believe is a GNU extension. I want to keep support for non-GNU OSes like *BSD and macOS. Needs some more work before adopting.

I cannot speak for *BSD but I'm pretty certain that asprintf is available on Mac. If you can require C99 or better it is of course possible to write a wrapper using the fact that `snprintf(nullptr, 0, format, ...)` returns the required buffer size, and do your own memory allocation. You'll just have to handle the varargs detail but that should be trivial using vsnprintf().

[rdmark]

@RJVB Thanks for the advice!

The portability might not have been as dire as I thought. With minor modifications this builds on Linux and FreeBSD: 8e433ee

There is some instability after a short while after mounting a fuse file system. Probably not related to this change, but more testing is needed.

[RJVB]

Good to hear! I'm a bit busy and don't have a lot of use for afp ATM but keep me updated if you need help with the testing and I'll see what I can do!

[rdmark]

@RJVB Cheers, thanks for the offer!

My main usecase for afpfs is because I'm the maintainer of Netatalk these days, and it's handy to have a testbed that's not dependent on an actual Mac. :)

FWIW I don't think anything I did broke Fuse. Even going back to the first commit in my fork, the mounted Fuse file system is super unstable. It either freezes the Debian system after 2-3 file operations, OR runs into inexplicable permission denied errors. I need to read up more on Fuse I think to make sure I haven't misconfigured it...

[RJVB]

FWIW I don't think anything I did broke Fuse. Even going back to the first commit in my fork, the mounted Fuse file system is super unstable. It either freezes the Debian system after 2-3 file operations, OR runs into inexplicable permission denied errors. I need to read up more on Fuse I think to make sure I haven't misconfigured it...

Actually, now that you mention it, that is probably the reason why I'm not using afpfs much, in particular not to keep the share on my TimeCapsule mounted under Linux. It's an older one that only does SMB1 so I had to figure out how to mount it with a more modern kernel but that's stable at least.

[rdmark]

Was afpfs Fuse mounted volumes really that unstable 9 years ago? I want to believe that something else, like subsequent changes in the Fuse library since is causing this…

Anyhow, on a positive note the afpcmd tools work remarkably well (after a few bug fixes by yours truly) and is perfectly serviceable for one-off file transfers.

[RJVB]

Was afpfs Fuse mounted volumes really that unstable 9 years ago?

I could check, since I probably haven't updated much (I prefer using my computers for other things than just keeping them uptodate ;) ) (I'm at Fuse 2.9.2 from what I can tell)

[RJVB]

Here's another reason why I might not be using afpfs all that much ;) TimeCapsule mounted via CIFS ``` 1/5 Sequential write [4MB] block Avg: 5.85MB/s Min÷Max: 3.09 ÷ 7.01, Time: 3m03s 2/5 Sequential read [4MB] block Avg: 5.19MB/s Min÷Max: 0.82 ÷ 9.79, Time: 3m17s 3/5 Random write [4KB] block Avg: 0.09MB/s Min÷Max: 0.05 ÷ 0.16, Time: 0m07s 4/5 Random read [4KB] block Avg: 0.33MB/s Min÷Max: 0.13 ÷ 1.69, Time: 0m07s 5/5 Memory copy [4MB] block Avg: 2600.05MB/s Min÷Max: 1442.19 ÷ 2982.67, Time: 0m04s Write Score*: 0.43 MB/s Read Score*: 1.18 MB/s *Calculation: average throughput with 80% read/written seqentialy and 20% randomly ``` Same TimeCapsule share mounted via afpfs: ``` 1/5 Sequential write [4MB] block Avg: 0.24MB/s Min÷Max: 0.18 ÷ 0.24, Time: 75m40s 2/5 Sequential read [4MB] block Avg: 0.99MB/s Min÷Max: 0.87 ÷ 1.06, Time: 17m13s 3/5 Random write [4KB] block Avg: 0.21MB/s Min÷Max: 0.08 ÷ 0.27, Time: 0m07s 4/5 Random read [4KB] block Avg: 0.21MB/s Min÷Max: 0.06 ÷ 1.01, Time: 0m07s 5/5 Memory copy [4MB] block Avg: 2584.32MB/s Min÷Max: 1419.04 ÷ 2984.31, Time: 0m04s Write Score*: 0.23 MB/s Read Score*: 0.53 MB/s *Calculation: average throughput with 80% read/written seqentialy and 20% randomly ``` I would have expected that the network and slowness of this NAS would have been the bottleneck but clearly not!