November 23rd, 2009
Okay, so we were _almost_ there last time. Indeed, all seemed fine except for those hellish devices that use DHCAST128 key-exchange, which still refused to start working with ForkLift, even after the 1.7.6 release.
Our first reaction was: Who needs those anyway?
But that was only our irrepressible sense of humor butting in, of course, and finally, we did sit down to reviewing the many diagnostic reports you sent in and started coding like we’re supposed to.
So, we are now the proud owners (more like the proud authors) of a DHCAST128 module which we were generous enough to share with you in this 1.7.7 build.
ForkLift 1.7.7 should now enable you, our esteemed users, to manage those network storages without any more problems.
So, without further ado, let’s see how it performs:
Download ForkLift 1.7.7
As usual, all feedback is welcome.
Good nights everyone
6 Comments
November 11th, 2009
I guess many of you are just as eager as we are to put an end to the AFP adventure ride we’ve been lost in for so long.
To take the next step though, we’ll need a bit of help from you.
Please, if you experienced broken AFP functionality the 1.7.6 release, run this diagnostic build for us.
The build detects what kind of protocols are used on the problem devices.
Here’s the build then: AFPInfoForkLift
and here’s how it works:
1. Launch the diagnostic build (first quit the regular copy of ForkLift)
2. Launch ‘Console’ with Spotlight
3. In the ForkLift Sidebar, click on the shared device to which ForkLift 1.7.6 failed to connect.
4. Something like this will show up in Console:
11/11/09 5:51:14 PM ForkLift[5510] ##### AFPINFO START: 10.0.10.168 #####
11/11/09 5:51:14 PM ForkLift[5510] versions: 4
11/11/09 5:51:14 PM ForkLift[5510] 10.0.10.168: supported protocols: AFP3.3
11/11/09 5:51:14 PM ForkLift[5510] 10.0.10.168: supported protocols: AFP3.2
11/11/09 5:51:14 PM ForkLift[5510] 10.0.10.168: supported protocols: AFP3.1
11/11/09 5:51:14 PM ForkLift[5510] 10.0.10.168: supported protocols: AFPX03
11/11/09 5:51:14 PM ForkLift[5510] uams: 5
11/11/09 5:51:14 PM ForkLift[5510] 10.0.10.168: supported uams: DHCAST128
11/11/09 5:51:14 PM ForkLift[5510] 10.0.10.168: supported uams: DHX2
11/11/09 5:51:14 PM ForkLift[5510] 10.0.10.168: supported uams: Recon1
11/11/09 5:51:14 PM ForkLift[5510] 10.0.10.168: supported uams: Client Krb v2
11/11/09 5:51:14 PM ForkLift[5510] 10.0.10.168: supported uams: No User Authent
11/11/09 5:51:14 PM ForkLift[5510] ##### AFPINFO END: 10.0.10.168 #####
5. Copy the output in Console (select lines from ##### AFPINFO START: ##### to ##### AFPINFO END: #####)
6. In an email to bugreport@binarynights.com describe the type of the device (eg. Synology Diskstation), and paste in the diagnostic output.
Thanks for your help
crew
2 Comments
November 3rd, 2009
ForkLift is complete once again.
As you probably noticed, we’ve passed the past 3-4 months in a quagmire called ‘ForkLift is no longer able to connect to AFP shares on Snow Leopard’.
It is difficult to describe the feeling – us, the self-proclaimed masters of connecting to all known devices failing to manage the most native form of sharing on Mac. For months we looked to Apple to magically send us a solution, but this proved to be an unreasonable hope. So, leaving Infinite Loop about 2 weeks ago, we decided to take matters in our own hands: to create our own implementation for AFP from scratch.
At the end of the first week we’ve lost about 40 hours of sleep each, immersed way above our heads in some real low-level stuff (handling Diffie–Hellman key exchange and such), we finally cracked the problem, coded our own procedures, and today we are proud to present our latest release, the one restoring ForkLift to its full splendor on SL:
More ▸
11 Comments
