Login  •  Register


The time is now: Fri Dec 13, 2019 2:37 am

Emaculation wiki  •  Delete all board cookies



Post new topic  Reply to topic Page 5 of 7 [ 157 posts ]    Go to page Previous  1, 2, 3, 4, 5, 6, 7  Next
Print view Previous topic  |  Next topic
Author Message
PostPosted: Sat Sep 30, 2017 5:38 pm 
Offline
Forum All-Star
User avatar

Joined: Fri Nov 27, 2009 5:11 am
Posts: 2757
Location: Emaculation.com
https://www.macports.org/install.php#installing

Are you installing the Snow Leopard version of MacPorts?


Top
 Profile  
Reply with quote Post a reply  
PostPosted: Sat Sep 30, 2017 9:21 pm 
Offline
Apple Corer
User avatar

Joined: Wed Apr 10, 2013 9:32 am
Posts: 279
Yes.

In the thread I referred to a few posts earlier I already reported issues when I tried it on ML. Back then you wrote that you installed it on SL and it would still work for you after updating to ML. Something seems to be broken still with the netatalk port. I wanted to test whether I could succeed in installing it on SL, copy the files (possibly whole macports) to ML and run an upgrade there.

I also tried it via afpfs-ng on top of FUSE for macOS. Installation/compilation worked. But I get errors trying to connect. It possibly interferes with Apple's own AFP implementation. But I don't know where/how to look for a solution. Neither do I know how to uninstall afpfs-ng :oops:

I don't desperately need this, I'm just very curious whether old and new systems could talk to each other via the network that way.


Top
 Profile  
Reply with quote Post a reply  
PostPosted: Sat Sep 30, 2017 11:35 pm 
Offline
Apple Corer
User avatar

Joined: Wed Apr 10, 2013 9:32 am
Posts: 279
It appears that afpfs-ng defaults to AFP version 3.2, but actually provides 2.2 as well. That is sufficient to connect to machines/emulators running Mac OS 7.6 and up.
OS X/macOS only provides 3.0 and higher.

According to https://github.com/007/afpfs-ng#usage I should use the mount_afp command to use afpfs.ng with fuse. But it appears that this command was already there before installing fuse and afpfs-ng, as Apple makes use of it in OS X.

Does anyone know how to call afpfs.ng with fuse in order to connect using AFP version 2.2?


Top
 Profile  
Reply with quote Post a reply  
PostPosted: Sun Oct 01, 2017 4:10 am 
Offline
Forum All-Star
User avatar

Joined: Fri Nov 27, 2009 5:11 am
Posts: 2757
Location: Emaculation.com
I don't, but since the source is available, we could probably trace through it. And to handle the mount_afp duplication, we could rename the FUSE versions to mount_afp2 and mount_afp3.

edit:

From https://github.com/007/afpfs-ng/blob/ma ... ATURES.txt :

Quote:
G. Networks
-----------

IPv6: There is no support for IPv6.
Appletalk: There is no support for Appletalk
IPv4: Yes, of course.

There's no concept of multiple protocols, eg. doing getstatus with one protocol,
then connecting with another, which is what some Apple clients do.

There's no ability to connect based on a name advertized by Bonjour/Avahi, you
need to use the IP or DNS name.


H. Server-specific information
------------------------------

afpfs-ng detects the server type by parsing the Machine Type field in
getstatus. The command line 'afpgetstatus' will show this without you having
to log in. 'status' will show you this also.

The detection is done in order to deal with some details.

1. Mac OS 8

afpfs-ng has never been used with Mac OS 8, so there's no data. You could do
this with AFP over TCP/IP, but this could be difficult. Email me if you have any info.

2. Mac OS 9

This speaks AFP 2.1, so this presents certain restrictions, such as:
- smaller limits on file and disk sizes (4GB)
- creating files larger than 2GB isn't possible and isn't handled properly
- 'df' will report a max of 4GB.
- no support for Unix privileges; all files are reported as 0600, directories
as 0700.
- for directories, timestamps are reported as the mount times, which is what
the Mac OS X client does.

There is no proper charset conversions for filenames. Patches accepted.

This has been lightly tested.

3. Mac OS X

Various versions have been tested, including 10.2, 10.3, 10.4 and 10.5.x. This has been most
heavily tested. Note the restrictions on UAMs above.

10.5 introduces AFP function 76, but there's no documentation on this. Too
bad.

4. Airport Extreme

The airport extreme with firmware 7.1 and 7.2.1 has been tested, and has two
oddities:

- Unix permissions aren't handled at all

- the device has a software bug which can let an authenticated user freeze the
device. I won't describe the problem in any more detail. Apple has
acknowledged the problem, but hasn't yet released updated firmware.

Note that the Airport can serve up SMB and AFP disks; afpfs-ng only handles
AFP.

5. Time Capsule

The Time Capsule is a network backup device meant to handle Time Machine
backups over AFP. This hasn't been released and my wife won't let me buy one,
so there's been no testing. Donations appreciated.

6. Netatalk

This open source server has a few issues, and afpfs-ng tries to work around
them. The most significant one is around file permissions; there's a bug in
older versions whereby some permissions cannot be set with a chmod (particularly
the execute bit on files).

It becomes a bit difficult to identify if you have the newer or older version
of netatalk since it has been changed in CVS, and occurred after 2.0.3. 2.0.4
hasn't been released yet (almost 3 years later). Some distributions (such as
Fedora 8) ship a broken version.

There's a patch available on the afpfs-ng download site, although grabbing a
later version of netatalk from CVS will work also.

After you attempt to 'chmod +x foo', 'status' will show you if it is broken or
not.


Top
 Profile  
Reply with quote Post a reply  
PostPosted: Sun Oct 01, 2017 9:51 am 
Offline
Apple Corer
User avatar

Joined: Wed Apr 10, 2013 9:32 am
Posts: 279
adespoton wrote:
I don't, but since the source is available, we could probably trace through it. And to handle the mount_afp duplication, we could rename the FUSE versions to mount_afp2 and mount_afp3.

I surely have more time than you (as you wrote about a backlog of projects in some other thread). If you can explain what exactly would have to be done (maybe fork it on github and just substitute "mount_afp" by "mount_afp1"?) I'm happy to do that.


adespoton wrote:

Thanks for pointing me to this information, I had not seen it.

I originally linked to 007's fork as it seemed to contain newer patches. But looking at the patches' names at https://github.com/simonvetter/afpfs-ng/network , it appears 007's are the same ones but only have been applied later. And as there are two extra patches by David Reid in Simon Vetter's fork, https://github.com/simonvetter/afpfs-ng/ seems to be the better choice.


adespoton wrote:
Quote:
G. Networks
-----------

IPv6: There is no support for IPv6.
Appletalk: There is no support for Appletalk
IPv4: Yes, of course.

There's no concept of multiple protocols, eg. doing getstatus with one protocol, then connecting with another, which is what some Apple clients do.

There's no ability to connect based on a name advertized by Bonjour/Avahi, you need to use the IP or DNS name.

This FEATURES.txt file is taken over from the last version (0.8) of the original developer and hasn't been updated since 10 years. I know there's no "AppleTalk" (DDP), but for the Mac OS versions Qemu is able to run we only need TCP/IP anyway.
However, IPv6 has been implemented in version 0.8.2 by Simon Vetter (see https://github.com/simonvetter/afpfs-ng#changelog).

There's no Bonjour, but it shouldn't be a big thing to write an AppleScript providing a dialog that lets you set the required information it will then pass to the command line for connecting in future. I suspect I would be able to find the required information to write such a script.
Alternatively, it would be possible to insert a suitable line into the bash script people use to start Qemu.


adespoton wrote:
Quote:
H. Server-specific information
------------------------------

afpfs-ng detects the server type by parsing the Machine Type field in getstatus. The command line 'afpgetstatus' will show this without you having to log in. 'status' will show you this also.

The detection is done in order to deal with some details.

1. Mac OS 8

afpfs-ng has never been used with Mac OS 8, so there's no data. You could do this with AFP over TCP/IP, but this could be difficult. Email me if you have any info.

2. Mac OS 9

This speaks AFP 2.1, so this presents certain restrictions, such as:
- smaller limits on file and disk sizes (4GB)
- creating files larger than 2GB isn't possible and isn't handled properly
- 'df' will report a max of 4GB.
- no support for Unix privileges; all files are reported as 0600, directories as 0700.
- for directories, timestamps are reported as the mount times, which is what the Mac OS X client does.

There is no proper charset conversions for filenames. Patches accepted.

This has been lightly tested.

[…]

The limitations of Mac OS 9 can't be helped, of course. Except I didn't think of the missing file name conversion and I don't think this has been added in version 0.8.2.

But if, for the time being, that would be the only real disadvantage, I think we would have a good solution to start with. (If I understand correctly, for now it's about exchanging files between Qemu and host.)


Top
 Profile  
Reply with quote Post a reply  
PostPosted: Mon Oct 02, 2017 1:37 am 
Offline
Forum All-Star
User avatar

Joined: Fri Nov 27, 2009 5:11 am
Posts: 2757
Location: Emaculation.com
The quick fork is what I was imagining, although you could probably do it in a local clone and then push it back upstream to prevent fragmentation. However, based on how the code actually looks, it appears that version selection is done as part of the handshake; it queries the AFP version, and then switches to that protocol.

No Bonjour probably won't be an issue, as we've got other discovery methods -- plus, we already know the host and guest IPs.

This actually looks to me like the code is modular enough that we could potentially bypass FUSE altogether and simply use the AFPFS command-line code integrated directly into QEMU sitting directly on top of SLiRP, if the devs would be OK with that.

But yeah; that's a fair bit of extra work. According to the docs, it should "just work" assuming you've got FUSE installed already.


Top
 Profile  
Reply with quote Post a reply  
PostPosted: Mon Oct 02, 2017 12:33 pm 
Offline
Apple Corer
User avatar

Joined: Wed Apr 10, 2013 9:32 am
Posts: 279
adespoton wrote:
The quick fork is what I was imagining, although you could probably do it in a local clone and then push it back upstream to prevent fragmentation. However, based on how the code actually looks, it appears that version selection is done as part of the handshake; it queries the AFP version, and then switches to that protocol.

But if mount_afp calls the version Apple shipped with the OS, does the system realise there's another version and use that when the server requires AFP 2.x?

I don't have any knowledge about the other things you wrote. I only know that plain command-line AFPFS requires to do everything through terminal, while using AFPFS with FUSE will pass it to the GUI.

What do you mean by "prevent fragmentation"? If you tell me it makes sense to fork FUSE or clone it locally and substitute mount_afp I will do so. And if you tell me how to compile a .pkg I will do so as well. Given the fact that the one available at https://osxfuse.github.io/ is compatible with OS X 10.5 up to present macOS versions, I suppose I could do that in my 10.6 VM with XCode installed? And what to add to compile for 10.5?

I should probably find out the answer when I perform the build instructions at https://github.com/osxfuse/osxfuse#build-instructions. But the better prepared I am the better chances are that I don't have to begin over. Having an overview first makes the mountain less high in my perception and keeps me motivated.


Top
 Profile  
Reply with quote Post a reply  
PostPosted: Tue Oct 03, 2017 3:23 am 
Offline
Forum All-Star
User avatar

Joined: Fri Nov 27, 2009 5:11 am
Posts: 2757
Location: Emaculation.com
Yes; I recall having issues when installing it last time where the built-in afpfs had loading priority over the afp-ng build. For convenience, it might be worth renaming it mount_afp2 (2 to indicate it handles v 2.x).

By preventing fragmentation, I mean that if we can keep one authoritative repository that we submit fixes to, it will be easier to track and survive longer; the existing forks already make it difficult to get a build with all the most recent patches applied.

At this point, I'd recommend two builds; one with the 10.6 VM as a 32-bit build (should be good for 10.5 through 10.7 or so) and a 64-bit build on High Sierra XCode that should work on 10.8 through 10.13 (and beyond). Since 10.14 likely will be 64-bit only by default (with some sport of compatibility layer likely), this will make it easier for people to figure out what to install.

It's been years since I've deployed via pkg though; a script in there should be able to take both compiled binaries and figure out which one needs to be installed, but I'd be useless at helping with this; there are others on here that may be able to help though.

Good luck! It'll take time to get it all working as expected, but the rest of us will sure appreciate it if you succeed :)


Top
 Profile  
Reply with quote Post a reply  
PostPosted: Tue Oct 03, 2017 6:33 pm 
Offline
Apple Corer
User avatar

Joined: Wed Apr 10, 2013 9:32 am
Posts: 279
Thanks for clarification. Then I'll work on it step by step.

When I use afpcmd or afpstatus (both only part of afpfs-ng, not of the built-in afpfs), this is what I get trying to connect to MacOS 9 capable of AFP version 2.x (no matter whether it runs in an emulator and on my old iMac booted from the MacOS 9 partition). It's the same for Mountain Lion and for Sierra running in a VM:
Code:
$ afpgetstatus afp://192.168.1.80
trying 192.168.1.95 ...
dyld: lazy symbol binding failed: Symbol not found: _iconv_open
  Referenced from: /usr/local/lib/libafpclient.0.dylib
  Expected in: flat namespace

dyld: Symbol not found: _iconv_open
  Referenced from: /usr/local/lib/libafpclient.0.dylib
  Expected in: flat namespace

Trace/BPT trap: 5
(This is for Mountain Lion, in Sierra the last line reads "Abort trap: 6".)

If I use a non-existant IP, I get the following message (so that can't be the reason for above message):
Code:
$ afpgetstatus afp://192.168.1.85
trying 192.168.1.85 ...
Connecting to server: Operation timed out

It works for my netatalk-NAS capable of AFP version 3.2:
Code:
$ afpgetstatus afp://192.168.1.81
trying 192.168.1.81 ...
Server name: bananapi
Machine type: Netatalk2.2.4
AFP versions:
     AFPVersion 1.1
     AFPVersion 2.0
     AFPVersion 2.1
     AFP2.2
     AFPX03
     AFP3.1
     AFP3.2
UAMs:
     No User Authent
     Cleartxt Passwrd
     Randnum Exchange
     2-Way Randnum Exchange
     DHCAST128
     DHX2
Signature: […]


Google brought up that it might be related to a duplicate library or something. But I couldn't find the problem. I have even deleted Homebrew and MacPorts with everything I installed through them (which I don't actively use anyway).

According to https://stackoverflow.com/questions/746 ... os-project "_iconv_open" refers to libiconv.dylib (libiconv.tbd from Xcode 7), and that lib would need to be included.

Anyone who can help?


Top
 Profile  
Reply with quote Post a reply  
PostPosted: Tue Oct 03, 2017 8:26 pm 
Offline
Forum All-Star
User avatar

Joined: Fri Nov 27, 2009 5:11 am
Posts: 2757
Location: Emaculation.com
I presume you already saw this, but it may help:
https://stackoverflow.com/questions/746 ... os-project

It looks like you may have to re-add the framework to the project, ensuring it's grabbing the correct one.

https://stackoverflow.com/questions/156 ... iconv-open indicates that when you're building from command line, other projects might get in the way.

At least one developer fixed it by re-installing the command line tools for XCode.


Top
 Profile  
Reply with quote Post a reply  
PostPosted: Wed Oct 04, 2017 12:30 am 
Offline
Apple Corer
User avatar

Joined: Wed Apr 10, 2013 9:32 am
Posts: 279
The second is not the case. I freshly installed Xcode and the Command Line Tools in the Sierra VM before writing my last post. And it came up with the same error as Mountain Lion.

The first might be the case. But after what I tried the last few hours I have to add an .xcodeproj file to the repository to enable pulling it into Xcode. But in order for that to work it seems I have to move everything into a subfolder. That would prevent merging anything into Simon Vetter's master branch.
I'd rather work in Terminal and don't touch anything that doesn't need to be touched. 'Just' need to find a way to reference to (or include?) libiconv.dylib.

After doing the AppleTalk (A2SERVER) NAS a while ago, this seems like the next step. But from my present position it looks like a big step.

EDIT:
In Xcode 9 under Sierra libiconv.dylib has a different name, of course. So it makes sense to re-install the Command Line Tools under Mountain Lion to be sure.


Top
 Profile  
Reply with quote Post a reply  
PostPosted: Wed Oct 04, 2017 8:22 pm 
Offline
Apple Corer
User avatar

Joined: Wed Apr 10, 2013 9:32 am
Posts: 279
Forget pulling into Xcode. Found the answer to the problem:
https://sourceforge.net/p/afpfs-ng/bugs/1/

Line 115
Code:
LIBS = @LIBS@
in afpfs-ng/cmdline/Makefile.in has to read
Code:
LIBS = @LIBS@ -liconv

I tested this in the Sierra VM. It compiled and this is what I get:
Code:
[code]LIBS = @LIBS@[/code]$ afpgetstatus afp://192.168.1.95
trying 192.168.1.95 ...
dsi_recv: Connection reset by peer
Server name: SheepShaver
Machine type: Macintosh
AFP versions:
     AFPVersion 1.1
     AFPVersion 2.0
     AFPVersion 2.1
UAMs:
     No User Authent
     Cleartxt Passwrd
     Randnum Exchange
     2-Way Randnum Exchange
Signature: 04ffff4604ffff4604ffff4604ffff46
This is SheepShaver running MacOS 9.0.4.

To be continued …


Top
 Profile  
Reply with quote Post a reply  
PostPosted: Wed Oct 04, 2017 8:51 pm 
Offline
Forum All-Star
User avatar

Joined: Fri Nov 27, 2009 5:11 am
Posts: 2757
Location: Emaculation.com
That's great! Thanks for sharing :) Let me know if you need me to test something in a different environment; I don't have much time, but this is looking quite promising.


Top
 Profile  
Reply with quote Post a reply  
PostPosted: Wed Oct 04, 2017 9:45 pm 
Offline
Apple Corer
User avatar

Joined: Wed Apr 10, 2013 9:32 am
Posts: 279
I've just created a pull request. Not sure whether Simon Vetter is still maintaining it. Else you can find the patched version at https://github.com/mabam/afpfs-ng.

I've also tested afpcmd in my Sierra VM:
Code:
$ afpcmd afp://192.168.1.95/share
Parsing afp://192.168.1.95/share
Successful parsing of URL
trying 192.168.1.95 ...
dsi_recv: Connection reset by peer
trying 192.168.1.95 ...
Connected to server SheepShaver using UAM "No User Authent"
Connected to volume share
afpcmd:
Copying a file was successful:
Code:
afpcmd: get Links.txt
    Getting file Links.txt
Transferred 299 bytes in 0.041 seconds. (0 kB/s)
afpcmd: quit
$

You're welcome to test on High Sierra. Compile as described here: https://github.com/mabam/afpfs-ng#installation, but use "./compile --disable-gcrypt" (gcrypt doesn't compile on macOS, and Classic Mac OS isn't capable of such encryption anyway). If you try it with Fuse, don't forget to opt for the compatibility layer when running the Fuse installer.

I'll see if I can locate the files afpfs-ng installed on my Mountain Lion machine and delete them. Then I'll test it there.

I might try to compile a .pkg at a later stage (if I can figure out how to do it). But first I want to get it to work with Fuse. So next will be changing mount_afp to mount_apf2 in a fork of FUSE for macOS.

By the way: In Snow Leopard mount_afp is able to connect to at least AFP 2.x (it worked for MacOS 9.0.4 in SheepShaver). I did not install fuse or afpfs. That is, in Snow Leopard Server in a Parallels VM.

I found that there is no Fuse in OS X/macOS. Only the command (mount_afp) is the same but belongs to the AFP functionality Apple shipped with the system (which might be derived from Fuse at some point in the past). The stuff I found on my Mountain Lion system has been installed by Parallels and is called prlufs.fs. It seems te be a fork of Fuse but doesn't use its commands.


Top
 Profile  
Reply with quote Post a reply  
PostPosted: Wed Oct 04, 2017 10:37 pm 
Offline
Forum All-Star
User avatar

Joined: Fri Nov 27, 2009 5:11 am
Posts: 2757
Location: Emaculation.com
When installing FUSE, you need to install OSXFUSE with the compatability layer. I can't remember now, but I think you may need to disable SIP on El Capitan and later prior to installing it to get it to function, as it installs into the System directory.


Top
 Profile  
Reply with quote Post a reply  
PostPosted: Wed Oct 04, 2017 10:47 pm 
Offline
Apple Corer
User avatar

Joined: Wed Apr 10, 2013 9:32 am
Posts: 279
I'm using the .pkg from https://osxfuse.github.io/. That's the only version they provide there, but it's for OS X 10.5 and up and has been released last month. So it also seems to be for present macOS versions.

The source I'll use for the amendments is on https://github.com/osxfuse/osxfuse. So then I will have to compile it anyway.

… Thanks for the tip regarding SIP. Wouldn't have thought of that.


Top
 Profile  
Reply with quote Post a reply  
PostPosted: Fri Oct 13, 2017 12:14 pm 
Offline
Space Cadet
User avatar

Joined: Fri Oct 13, 2017 12:06 pm
Posts: 1
Hello guys :)
I'm new here and I recently found out that the emulation of Mac OS 9.2.2 is finally possible with the QEMU.

I just wanted to thank all of the people whom made this possible. It was a dream come true.

Great Job! Thanks a lot :wink:


Top
 Profile  
Reply with quote Post a reply  
PostPosted: Mon Oct 16, 2017 9:02 pm 
Offline
Apple Corer
User avatar

Joined: Wed Apr 10, 2013 9:32 am
Posts: 279
I have figured that the mount-afp command is not implemented in FUSE, but is part of afpfs-ng.

When installing in a Ubuntu VM, I had to use Simon Vetter's afpfs-ng as the -iconv fix in my fork actually broke it on that system. But the stuff needed for FUSE did compile and I could connect to SheepShaver via FUSE (that is, using mount_afp).
For anyone interested, compile and install on Ubuntu (and possibly other Linux flavours) without gcrypt (which does not work with Classic MacOS anyway) as follows:
Code:
sudo apt-get install libgmp3-dev readline-common libreadline6 libreadline6-dev libfuse2 libfuse-dev libncurses5-dev
Code:
wget https://github.com/simonvetter/afpfs-ng/archive/master.zip
Code:
unzip master.zip
Code:
cd afpfs-ng-master
Code:
sudo ./configure --prefix=/usr --disable-gcrypt
Code:
sudo make install
(Adapted from http://yarenty.blogspot.com/2014/12/ubuntu-1404-apple-time-capsule.html.)

On OS X/macOS I figured by default the part to make afpfs-ng work via FUSE is not compiled. Theoretically one has to add "--enable-fuse" to compile those components. But practically they don't compile even then. This has to be fixed first. I'll try to do so but am not sure whether I will be able to.
I think it's all about lines 21667 to 21911 of the configure file. What I understand of it is that if it recognizes OS X/macOS (Darwin) as host, it will check whether "--enable-fuse" was entered while running "./configure", and lateron checks whether FUSE is installed on the host system. There is much more going which I do not (yet?) understand. Any help is very much appreciated!

Here's the code, but it's much easier to read at https://github.com/mabam/afpfs-ng/blob/libiconv/configure#L21667:
Code:
case $host in
   *-*-darwin*)
   ;;
   *)
   # Check whether --enable-fuse was given.
if test "${enable_fuse+set}" = set; then
  enableval=$enable_fuse;
fi
   if test "x$enable_fuse" != "xno" ; then
      old_cflags=$CFLAGS
      old_cppflags=$CPPFLAGS
      CFLAGS="$CFLAGS -D_FILE_OFFSET_BITS=64 -DFUSE_USE_VERSION=26 "
      CPPFLAGS="$CPPFLAGS -D_FILE_OFFSET_BITS=64"
for ac_header in fuse.h
do
as_ac_Header=`echo "ac_cv_header_$ac_header" | $as_tr_sh`
if { as_var=$as_ac_Header; eval "test \"\${$as_var+set}\" = set"; }; then
  { echo "$as_me:$LINENO: checking for $ac_header" >&5
echo $ECHO_N "checking for $ac_header... $ECHO_C" >&6; }
if { as_var=$as_ac_Header; eval "test \"\${$as_var+set}\" = set"; }; then
  echo $ECHO_N "(cached) $ECHO_C" >&6
fi
ac_res=`eval echo '${'$as_ac_Header'}'`
          { echo "$as_me:$LINENO: result: $ac_res" >&5
echo "${ECHO_T}$ac_res" >&6; }
else
  # Is the header compilable?
{ echo "$as_me:$LINENO: checking $ac_header usability" >&5
echo $ECHO_N "checking $ac_header usability... $ECHO_C" >&6; }
cat >conftest.$ac_ext <<_ACEOF
/* confdefs.h.  */
_ACEOF
cat confdefs.h >>conftest.$ac_ext
cat >>conftest.$ac_ext <<_ACEOF
/* end confdefs.h.  */
$ac_includes_default
#include <$ac_header>
_ACEOF
rm -f conftest.$ac_objext
if { (ac_try="$ac_compile"
case "(($ac_try" in
  *\"* | *\`* | *\\*) ac_try_echo=\$ac_try;;
  *) ac_try_echo=$ac_try;;
esac
eval "echo \"\$as_me:$LINENO: $ac_try_echo\"") >&5
  (eval "$ac_compile") 2>conftest.er1
  ac_status=$?
  grep -v '^ *+' conftest.er1 >conftest.err
  rm -f conftest.er1
  cat conftest.err >&5
  echo "$as_me:$LINENO: \$? = $ac_status" >&5
  (exit $ac_status); } && {
    test -z "$ac_c_werror_flag" ||
    test ! -s conftest.err
       } && test -s conftest.$ac_objext; then
  ac_header_compiler=yes
else
  echo "$as_me: failed program was:" >&5
sed 's/^/| /' conftest.$ac_ext >&5
   ac_header_compiler=no
fi
rm -f core conftest.err conftest.$ac_objext conftest.$ac_ext
{ echo "$as_me:$LINENO: result: $ac_header_compiler" >&5
echo "${ECHO_T}$ac_header_compiler" >&6; }
# Is the header present?
{ echo "$as_me:$LINENO: checking $ac_header presence" >&5
echo $ECHO_N "checking $ac_header presence... $ECHO_C" >&6; }
cat >conftest.$ac_ext <<_ACEOF
/* confdefs.h.  */
_ACEOF
cat confdefs.h >>conftest.$ac_ext
cat >>conftest.$ac_ext <<_ACEOF
/* end confdefs.h.  */
#include <$ac_header>
_ACEOF
if { (ac_try="$ac_cpp conftest.$ac_ext"
case "(($ac_try" in
  *\"* | *\`* | *\\*) ac_try_echo=\$ac_try;;
  *) ac_try_echo=$ac_try;;
esac
eval "echo \"\$as_me:$LINENO: $ac_try_echo\"") >&5
  (eval "$ac_cpp conftest.$ac_ext") 2>conftest.er1
  ac_status=$?
  grep -v '^ *+' conftest.er1 >conftest.err
  rm -f conftest.er1
  cat conftest.err >&5
  echo "$as_me:$LINENO: \$? = $ac_status" >&5
  (exit $ac_status); } >/dev/null && {
    test -z "$ac_c_preproc_warn_flag$ac_c_werror_flag" ||
    test ! -s conftest.err
       }; then
  ac_header_preproc=yes
else
  echo "$as_me: failed program was:" >&5
sed 's/^/| /' conftest.$ac_ext >&5
  ac_header_preproc=no
fi
rm -f conftest.err conftest.$ac_ext
{ echo "$as_me:$LINENO: result: $ac_header_preproc" >&5
echo "${ECHO_T}$ac_header_preproc" >&6; }
# So?  What about this header?
case $ac_header_compiler:$ac_header_preproc:$ac_c_preproc_warn_flag in
  yes:no: )
    { echo "$as_me:$LINENO: WARNING: $ac_header: accepted by the compiler, rejected by the preprocessor!" >&5
echo "$as_me: WARNING: $ac_header: accepted by the compiler, rejected by the preprocessor!" >&2;}
    { echo "$as_me:$LINENO: WARNING: $ac_header: proceeding with the compiler's result" >&5
echo "$as_me: WARNING: $ac_header: proceeding with the compiler's result" >&2;}
    ac_header_preproc=yes
    ;;
  no:yes:* )
    { echo "$as_me:$LINENO: WARNING: $ac_header: present but cannot be compiled" >&5
echo "$as_me: WARNING: $ac_header: present but cannot be compiled" >&2;}
    { echo "$as_me:$LINENO: WARNING: $ac_header:     check for missing prerequisite headers?" >&5
echo "$as_me: WARNING: $ac_header:     check for missing prerequisite headers?" >&2;}
    { echo "$as_me:$LINENO: WARNING: $ac_header: see the Autoconf documentation" >&5
echo "$as_me: WARNING: $ac_header: see the Autoconf documentation" >&2;}
    { echo "$as_me:$LINENO: WARNING: $ac_header:     section \"Present But Cannot Be Compiled\"" >&5
echo "$as_me: WARNING: $ac_header:     section \"Present But Cannot Be Compiled\"" >&2;}
    { echo "$as_me:$LINENO: WARNING: $ac_header: proceeding with the preprocessor's result" >&5
echo "$as_me: WARNING: $ac_header: proceeding with the preprocessor's result" >&2;}
    { echo "$as_me:$LINENO: WARNING: $ac_header: in the future, the compiler will take precedence" >&5
echo "$as_me: WARNING: $ac_header: in the future, the compiler will take precedence" >&2;}
    ;;
esac
{ echo "$as_me:$LINENO: checking for $ac_header" >&5
echo $ECHO_N "checking for $ac_header... $ECHO_C" >&6; }
if { as_var=$as_ac_Header; eval "test \"\${$as_var+set}\" = set"; }; then
  echo $ECHO_N "(cached) $ECHO_C" >&6
else
  eval "$as_ac_Header=\$ac_header_preproc"
fi
ac_res=`eval echo '${'$as_ac_Header'}'`
          { echo "$as_me:$LINENO: result: $ac_res" >&5
echo "${ECHO_T}$ac_res" >&6; }
fi
if test `eval echo '${'$as_ac_Header'}'` = yes; then
  cat >>confdefs.h <<_ACEOF
#define `echo "HAVE_$ac_header" | $as_tr_cpp` 1
_ACEOF
fi
done
      if test "x$ac_cv_header_fuse_h" != "xyes" ; then
         { { echo "$as_me:$LINENO: error: FUSE is not installed.  To build without fuse, configure with '--disable-fuse'" >&5
echo "$as_me: error: FUSE is not installed.  To build without fuse, configure with '--disable-fuse'" >&2;}
   { (exit 1); exit 1; }; }
      fi
{ echo "$as_me:$LINENO: checking for fuse_main in -lfuse" >&5
echo $ECHO_N "checking for fuse_main in -lfuse... $ECHO_C" >&6; }
if test "${ac_cv_lib_fuse_fuse_main+set}" = set; then
  echo $ECHO_N "(cached) $ECHO_C" >&6
else
  ac_check_lib_save_LIBS=$LIBS
LIBS="-lfuse  $LIBS"
cat >conftest.$ac_ext <<_ACEOF
/* confdefs.h.  */
_ACEOF
cat confdefs.h >>conftest.$ac_ext
cat >>conftest.$ac_ext <<_ACEOF
/* end confdefs.h.  */
/* Override any GCC internal prototype to avoid an error.
   Use char because int might match the return type of a GCC
   builtin and then its argument prototype would still apply.  */
#ifdef __cplusplus
extern "C"
#endif
char fuse_main ();
int
main ()
{
return fuse_main ();
  ;
  return 0;
}
_ACEOF
rm -f conftest.$ac_objext conftest$ac_exeext
if { (ac_try="$ac_link"
case "(($ac_try" in
  *\"* | *\`* | *\\*) ac_try_echo=\$ac_try;;
  *) ac_try_echo=$ac_try;;
esac
eval "echo \"\$as_me:$LINENO: $ac_try_echo\"") >&5
  (eval "$ac_link") 2>conftest.er1
  ac_status=$?
  grep -v '^ *+' conftest.er1 >conftest.err
  rm -f conftest.er1
  cat conftest.err >&5
  echo "$as_me:$LINENO: \$? = $ac_status" >&5
  (exit $ac_status); } && {
    test -z "$ac_c_werror_flag" ||
    test ! -s conftest.err
       } && test -s conftest$ac_exeext &&
       $as_test_x conftest$ac_exeext; then
  ac_cv_lib_fuse_fuse_main=yes
else
  echo "$as_me: failed program was:" >&5
sed 's/^/| /' conftest.$ac_ext >&5
   ac_cv_lib_fuse_fuse_main=no
fi
rm -f core conftest.err conftest.$ac_objext conftest_ipa8_conftest.oo \
      conftest$ac_exeext conftest.$ac_ext
LIBS=$ac_check_lib_save_LIBS
fi
{ echo "$as_me:$LINENO: result: $ac_cv_lib_fuse_fuse_main" >&5
echo "${ECHO_T}$ac_cv_lib_fuse_fuse_main" >&6; }
if test $ac_cv_lib_fuse_fuse_main = yes; then
  cat >>confdefs.h <<_ACEOF
#define HAVE_LIBFUSE 1
_ACEOF
  LIBS="-lfuse $LIBS"
fi
      CFLAGS=$old_cflags
      CPPFLAGS=$old_cppflags
      LIBFUSE_LDFLAGS="-lfuse"
       if true; then
  HAVE_LIBFUSE_TRUE=
  HAVE_LIBFUSE_FALSE='#'
else
  HAVE_LIBFUSE_TRUE='#'
  HAVE_LIBFUSE_FALSE=
fi
   fi
   ;;
esac


afpsfs-ng doesn't seem to be maintained anymore but is good as is for Linux. So I'll just use my fork for OS X/macOS with the mount_afp2 command then (once the above is fixed, changing to mount_afp2 shouldn't be the problem).

I don't have much time presently. But I'd love to get this to work.


Top
 Profile  
Reply with quote Post a reply  
PostPosted: Thu Oct 19, 2017 10:53 pm 
Offline
Apple Corer
User avatar

Joined: Wed Apr 10, 2013 9:32 am
Posts: 279
I've hacked a bit and this is as far as I got:

After downloading https://github.com/mabam/afpfs-ng/archive/libiconv.zip and unzipping it, I cd'd into it in Terminal and changed the "mount_afp" command to "mount_afp2" (I've found entries similar to these on the web):
Code:
grep -lr -e "mount_afp" . | xargs sed -i "" 's/mount_afp/mount_afp2/g'
Code:
grep -lr -e "MOUNT_AFP" . | xargs sed -i "" 's/MOUNT_AFP/MOUNT_AFP2/g'
Code:
mv ./fuse/mount_afp.1 ./fuse/mount_afp2.1


I then amended the line
Code:
#include <fuse.h>
in fuse/fuse_int.c to
Code:
#include </usr/local/include/fuse.h>
since afpfs-ng expects FUSE in a different location than the OSXFUSE installer puts the FUSE compatibility layer.


Same goes for fuse/commands.c. Change the line
Code:
#define FUSE_DEVICE "/dev/fuse0"
to
Code:
#define FUSE_DEVICE "/dev/osxfuse0"


Before compiling afpfs-ng, FUSE needs to be loaded:
Code:
/Library/Filesystems/osxfuse.fs/Contents/Resources/load_osxfuse
This will generate a number of /dev/osxfuse… virtual devices. Else compiling will fail at fuse/commands.c.


Now run:
Code:
./configure --disable-gcrypt --enable-fuse
Code:
make
Code:
sudo make install

This doesn't install the FUSE components yet, so also run:
Code:
cd fuse
Code:
make
Code:
sudo make install


The response to
Code:
sudo mkdir /Volumes/share
Code:
sudo mount_afp2 afp://192.168.1.95/share /Volumes/share
is
Code:
The afpfs daemon does not appear to be running for uid 0, let me start it for you
dsi_recv: Connection reset by peer
Mounting share from 192.168.1.95 on /Volumes/share
Volume share changes the server's encoding
Mounting of volume share from SheepShaver succeeded.

But the folder "share" disappears in Finder and Terminal.

If I change permissions for MacFUSE to user:staff and mount to ~/share without sudo, "cd ~/share" in Terminal results in:
Code:
-bash: cd: share: Input/output error


What could be the reason for the problems with mounting?


EDIT:
Corrected amendments to fuse/commands.c, deleted some other steps and require sudo.

EDIT2:
Again corrected amendments to fuse/commands.c and inserted manual loading of FUSE.


Top
 Profile  
Reply with quote Post a reply  
PostPosted: Sat Oct 21, 2017 12:19 pm 
Offline
Apple Corer
User avatar

Joined: Wed Apr 10, 2013 9:32 am
Posts: 279
adespoton wrote:
When installing FUSE, you need to install OSXFUSE with the compatability layer. I can't remember now, but I think you may need to disable SIP on El Capitan and later prior to installing it to get it to function, as it installs into the System directory.

Disabling SIP was not necessary for OSXFUSE. But as afpfs-ng with OSXFUSE doesn't properly mount volumes, I thought it might be related to the fact that afpfs-ng is not actively developed anymore while OSXFUSE probably moved a bit away from (Linux) FUSE, which afpfs-ng was developed for originally.

I still have the goal to make it work with OSXFUSE. But I'm curious to see how I fare using FUSE4X which is a few years old but available for present macOS versions via Fink. I figured I will have to disable SIP in order to have Sierra accept the unsigned FUSE4X .kext (I have found a guide for disabling SIP in a VirtualBox VM).

I plan to continue this after my vacation.


Top
 Profile  
Reply with quote Post a reply  
PostPosted: Mon Oct 30, 2017 12:00 am 
Offline
Apple Corer
User avatar

Joined: Wed Apr 10, 2013 9:32 am
Posts: 279
I succeeded with FUSE4X. Mounting a volume from MacOS 9.0.2 in SheepShaver via MOUNT_AFP2 worked.

I wouldn't be surprised if the amendments I had to make for FUSE4X will also work for OSXFUSE. I'll test that once I have the time.


EDIT:
FUSE4X only works as long as SIP is disabled. It seems to be possible to partially (but permanently) disable SIP so it allows loading of unsigned kexts: https://www.tonymacx86.com/threads/disabling-s-i-p-on-sierra.203597/. But I'll only dig deeper into that if I can't get it to work with OSXFUSE.


Top
 Profile  
Reply with quote Post a reply  
PostPosted: Mon Oct 30, 2017 8:26 pm 
Offline
Apple Corer
User avatar

Joined: Wed Apr 10, 2013 9:32 am
Posts: 279
It works using OSXFUSE!

The detour via FUSE4X was most helpful as FUSE4X actually prints error messages where OSXFUSE doesn't. The fix for OSXFUSE was the same I discovered trying FUSE4X.

Here I've mounted volumes from SheepShaver running MacOS 9.0.4 (AFP 2.1) and from an old iMac running MacOS 9.2 (AFP 2.2). Both from within a VirtualBox VM running Sierra:

Image

More information to follow …


Top
 Profile  
Reply with quote Post a reply  
PostPosted: Mon Oct 30, 2017 10:05 pm 
Offline
Forum All-Star
User avatar

Joined: Fri Nov 27, 2009 5:11 am
Posts: 2757
Location: Emaculation.com
Great work! I'm looking forward to deploying your solution. It seems like the most appropriate method of file sharing between qemu 9.x and OS X.


Top
 Profile  
Reply with quote Post a reply  
PostPosted: Mon Oct 30, 2017 11:37 pm 
Offline
Apple Corer
User avatar

Joined: Wed Apr 10, 2013 9:32 am
Posts: 279
I've just pushed the changes to https://github.com/mabam/afpfs-ng-OSX. I've also written a new README which should provide all required instructions.

Only tested on Sierra so far.


EDIT:
If I manage to compile this into a .pkg, that would ease installation a lot. But for the time being Xcode and command line tools are required.


EDIT 2:
Fixed a typo in my afpfs-ng github repository that prevented compilation of the fuse components.


Last edited by mabam on Tue Oct 31, 2017 5:33 pm, edited 1 time in total.


Top
 Profile  
Reply with quote Post a reply  
PostPosted: Tue Oct 31, 2017 1:26 pm 
Offline
Apple Corer
User avatar

Joined: Wed Apr 10, 2013 9:32 am
Posts: 279
Here's a documentation of the changes I made after forking afps-ng from Simon Vetter and cloning the repository to my desktop with Terminal:

I used vim to hard code the location of 'fuse.h' into 'fuse/fuse_int.c':
Code:
Change the line
#include <fuse.h>
to
#include </usr/local/include/fuse.h>

Then I corrected the name of the fuse device in 'fuse/commands.c' as required by OSXFUSE:
Code:
Change the line
#define FUSE_DEVICE "/dev/fuse0"
to
#define FUSE_DEVICE "/dev/osxfuse0"

It appeared that '-liconv' didn't only need to get added to 'cmdline/Makefile.in', but also to every other instance of 'LIBS = @LIBS@'. The following command searches for files containing those instances and passes them on to sed for doing the amendments:
Code:
grep -lr --exclude-dir=".git" -e "LIBS = @LIBS@" . | xargs sed -i "" 's/LIBS = @LIBS@/LIBS = @LIBS@ -liconv/g'

Also all references to the fuse library had to be corrected to match OSXFUSE's name and location of the library:
Code:
grep -lr --exclude-dir=".git" -e "-lfuse" . | xargs sed -i "" 's/-lfuse/\/usr\/local\/lib\/libosxfuse.la/g'

Finally, all instances of the 'mount_afp' command had to be changed to 'mount_afp2'. With the exception of the Git index file and some documentation files:
Code:
grep -lr --exclude-dir=".git" -e "MOUNT_AFP" . | xargs sed -i "" 's/MOUNT_AFP/MOUNT_AFP2/g'

grep -lr --exclude-dir=".git" -e "mount_afp" . | grep -vwE "(NEWS|README.md)" | xargs sed -i "" 's/mount_afp/mount_afp2/g'

mv ./fuse/mount_afp.1 ./fuse/mount_afp2.1

I wish I knew how to properly code the changes and make them apply only if installed on macOS / OS X. But at least this works.

Instructions on compilation/installation are in the README I mentioned in my last post.


To do/issues
(Any help is welcome!)

    • Test on as many versions of macOS / OS X as possible (Snow Leopard and up as this is where AFP 2.x support was dropped). I have successfully tested it on Snow Leopard, Mountain Lion and Sierra..
    .

    • Next to compilation into a .pkg, an AppleScript providing a GUI to afpfs-ng would be of use..
    .

    • The mounted volumes have names in the range of 'OSXFUSE Volume 0 (afpfsd)', which makes it difficult to discern between them if more than one volume is mounted. Adding '-o volname=<volname>' to the syntax should define a volume name. But I can't get it to work..
    .

    • Mounted volumes do only appear at the specified mount point, not in the side bar of a Finder window (for other file systems they seem to do that, see first post here).
    EDIT: If you have dragged it to the side bar under devices once, it will appear there automatically when you mount it again later (this might be normal behaviour of the Finder – I don't remember)..
    .

    • After unmounting a volume, sometimes the folder that was used as node is invisible in Finder (I only had that issue in Sierra). However, it is visible in Terminal and can be deleted there using 'rmdir <node>'..
    .

    • If you have two or more volumes mounted from the same server, unmounting one of them will unmount them all..
    .

    • Conversion of the encoding of file names would be great. CAP, which can be found in my other repository on github, provides that. Just like afpfs-ng, it is written in C. But I have no programming skills, and I doubt anyone who does have them is willing to invest the time for merging stuff into afpfs-ng to fix the encoding – just so that a few freaks still using Classic MacOS have more toys to play with :smile:..
    .

    • Files on a mounted volume always show 1 January 1970 as creation date..
    .

    • On macOS / OS X the format of an OSXFUSE volume is reported as "Generic File System (OSXFUSE)". This results in the Finder:
    - creating .DS_Store and AppleDouble files visible in the emulator,
    - being unable to read the resource fork of a file stored on the volume by Classic MacOS.
    At least Classic MacOS knows it's an HFS volume and doesn't add to the mess. BlueHarvest could be used to define mounts it will prevent the Finder to write metadata to..
    .

    • It seems that volumes mounted with OSXFUSE (or at least with afpfs-ng via OSXFUSE) can't be used with rsync. But I discovered that by accident and didn't do further investigation.


Top
 Profile  
Reply with quote Post a reply  
Display posts from previous:  Sort by  
Post new topic  Reply to topic Page 5 of 7 [ 157 posts ]    Go to page Previous  1, 2, 3, 4, 5, 6, 7  Next


Who is online

Users browsing this forum: No registered users and 2 guests


You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
 

Search for:
Jump to:  
Powered by phpBB® Forum Software © phpBB Group