BinaryNights is looking to recruite some extra hands for the pre-beta tests of ForkLift 2.0.

The app is still a long way (months) from complete, but we’re ready with some basic parts that we want tested in as many ways as possible.

Needless to say, we’re primarily looking for expert users with exceptionally acute observational capabilities, but also people who rely heavily on specific features and can provide some insight into optimizing workflow.

If you feel you can help us in the coming weeks please send us your forum user name to supportATbinarynightsDOTcom, and tell us in a few words what are your primary uses for ForkLift.

This pre-Beta is still a closed test, so you must be aware that everything you learn during the test period is confidential.

Good nights everyone

But we’re not going to give it to you without a speech first, because we want to share with you a short look back at last year, the excitement we feel towards the next

2009 has been an incredibly busy year, I guess for everyone, but certainly so for us. It new seems incredible that just 12 months ago we were in the runup of releasing ForkLift 1.6.
This was the release that introduced the great new UI and workflow that made ForkLift the synonym for cutting edge file manipulation on OS X Leopard, or so I hear.
Halfway into the year arrived ForkLift 1.7, our Coming of Age release. With the new major features of folder synchronization, folder merge, and terminal access added in this version, ForkLift finally became the application we all had visioned when we started out in 2007.

At this point, it was really time to lay back and take up World of Warcraft for a while, but instead we started working in secret on the next major release of ForkLift – the big 2.0.
Indeed, the core 1.x framework was over 2 years old at that time, and we felt we have learned enough to significantly improve ForkLift by doing a complete rewrite of the app, a true v2.0.

And while we were slightly held back by the unexpected difficulties of the 1.x version with the upgrade to Snow Leopard, we kept it tight in hand and managed to maintain the current version and at the same time to make good progress with 2.0.
So much that I’m happy to say we’re still shooting for a March release of the first public beta.

And one more thing. In 2009, the number of ForkLift users has passed the 20000 mark. Thanks everyone for that

Now we can get back to this shiny new year and this new release.

ForkLift 1.7.8 fixes a couple of issues, still under the sign of the Snow Leopard aftermath. Here’s a list

FIXES
- Move to bug: we hope to catch this one in time. Several users reported this bug, that ForkLift (and the filesystem) fails to report it when an error occurs on the target volume during a Move operation on Snow Leopard. This could potentially cause loss of files, so this is the most important fix of this release.

- invert selection: the keyboard shortcut assigned in the Commander set didn’t work properly.

- get info owner: the get info dialogue failed to correctly display file owners after the ownership was changed on a file.

- move to menu item: the Move to menu stayed active for local-to-remote transfers, although the operation is supported. This is now fixed.

- open enclosing folder: the operation was broken on Spotlight search results. Fixed.

- typos: corrected some UI typos

That’s all for tonight folks. Stay tuned!

Details

The headline being, in this case, a reference to the more mundane act of collecting money for our XMAS presents ;-P

The atmosphere of kindness and instinct to spread joy naturally commanding this time of the year has prompted us to organize yet another great PROMO for our beloved public, where everyone gets a present – you a copy of the most professional file manager created by human ingenuity, and us the better part of $9.95 after each purchase.

To us, this sounds like a perfect manifestation of the holiday spirit.

So, from this time until Christmas Eve ForkLift will be available for $9.95

Happy holidays everyone

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

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

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:

ForkLift 1.7.6 ! Get it while it’s hot!

With version 1.7.6 Snow Leopard users can again connect to AFP shares on their local network by simply clicking the shared resource’s icon in the Sidebar, in the usual manner.
So things are back to normal, and we can go back focusing on version 2.0. There is also a positive byproduct: having our own implementation means we now have a solution that will work reliably on all current and future versions of OS X.

This release also contains a handful of other fixes:

Amazon S3 connections cured
in some cases, ForkLift reported successful transfer of files to an S3 volume even though the operation was completed only partially. Thanks are owned in part to the guys who helped us track this one down.
Also, we’ve fixed another major issue we had with S3, and that is default ACL handling. S3 connections’ default ACL setting (public, private-read, private-write, authenticated-write) will now be applied correctly to all files uploaded through the given connection.

Flawless Eject returns
Several users reported problems ejecting mounted devices and shares, with short hangs and ForkLift preventing ejecting devices even through Finder. We expect this to be working again as well.

Go To Folder
Hitting ‘Go’ with the destination field empty produced a crash. Fixed

With this I conclude this post, the last in our series on service releases for Snow Leopard.

Good nights everyone

ForkLift 2.0 will be 64-bit, and Snow Leopard only.

I know from experience that announcements of this sort often fail to provoke the merry cries we normally expect.

So, just say it out loud a couple of times and let the warmth of the promise of a bright future wash over you. Because I know some questions inevitably pop up: What’s gonna happen to PPC users? Screw that, what’s gonna happen to Leopard users?

Well, first, stay calm, there’s no immediate threat. This is an early warning, ForkLift 2.0 is still a good way away. In fact, we don’t expect a beta before first quarter of 2010.

Second, we’ve had this same dilemma when moving from Tiger to Leopard, and speaking from experience, that all came out well in the end. Most people simply switched to Leopard sooner or later (rather sooner), and the few people who still use ForkLift 1.2 to this day seem pretty happy with the software they have. Also, let’s face it, the last PPC models were sold in 2006, about the time BinaryNights started out.

That said, let’s look at the upside.

Obviously, 64-bit is the way to go. I’ve always abhorred the though of being limited to 4294967295 of anything on my computers. Also, we like the efficiency of the 64-bit architecture. Efficiency is good. Grand Central Dispatch and easier handling of multithreaded code, both new tools in SL, are also great, although BinaryNights is one of those developer workshops where multithreaded programming was never a challenge, so some of these new features will not affect ForkLift so much.

What does affect ForkLift a great deal is the new set of system APIs that shipped with Snow Leopard. I’ll explain.

About 6 months ago, we decided that the time was ripe for some radical programming. ForkLift 1.x was having its 2nd birthday, and the first bits of code we wrote were over 3 years old. At that point, we felt we had enough experience to write a REALLY good file manager.

Thus we started working on ForkLift 2.0, basically from scratch.

By the time we’ve set up the general framework, Snow Leopard was released to developers, and we were faced with radical changes in our working environment, namely the system APIs through which ForkLift interacts with OS X.
In fact, our current problems with ForkLift 1.7.5 in handling AFP shares is related to the arrival of this new API set -or rather, the discontinued support for older APIs. The past 2 months of patching up ForkLift 1.7.x. to make it run on Snow Leopard gave us a very nice excursion into the realms of this new API set, and also made it clear that this is indeed a brand new horse we need to ride. We all know that riding both horses -the new and the old API sets- can only lead to half-assed solutions, and indeed, we feel sadness at the sight of fellow developers attempting to make the stunt.

Since ForkLift 2.0 is a complete rewrite of the project, going for the new architecture and new APIs was an obvious decision to make. The particulars are, as always, more complex, but the bottom line is: we want to keep our code as simple and robust as possible, to be able to maintain and evolve the code as fluidly as possible, and the system features in Snow Leopard will support this very well.

Of course, it feels a bit like starting on a mission to Mars – there’s this vision, quite detailed, of a bright new future before us, but still with months of tedious traveling before actually getting there.
The ETA for ForkLift 2.0 is Q1 2010.

Good nights everyone,