Still, it’s now the beginning of March and we had to realize we owe some updates.

As you might know, we’ve started a closed beta testing a while back. There are now over 40 people playing around with ForkLift2 and it is starting to behave more and more like a file manager should.

We’ve recently released the 12th test build, and there 167 tickets have been submitted to our bugtracker so far. And it feels like we’re going to climb into the third and fourth digits before this is over.

What we have so far is a pretty sound pretty new FTP/SFTP engine that works great, is superfast, and is free from problems even when connecting to non-standard servers. Users who have been troubled by timeout errors on some servers will also find their lives easier. The new code also fixes earlier problems with managing network shares. FL2 will now let you connect manually to local samba and other shares when they are not detected automatically. FL 1.x’s recurring problems with windows shares (especially the slow browsing of these volumes since the Sno Leo update) seem to have been cured.

The new engine will also authenticate you to handle files and folders to which the user with which you are logged in has no access privileges to (an issue we had hanging there for some time now). Also, FL2 will have a transfer queue, another feature that has been requested many times. FL2 will also include a transcript log for FTP transfers, again a piece of candy for powerusers.

The two panels have been retooled from the ground. Attentive readers probably know it already, but FL2 will have Column, Icon and Coverflow views.

In the panels too, we’ve fixed a couple of things that have been nagging us for a while. For instance, retaining panel positions and sort orders inside the panels between quitting and restarting ForkLift has been a problem issue in 1.x which we’ve now thoroughly fixed, and even introduced some new workplace management feature that we think massive FL users will find to be very gratifying.

About current status: there are still some actual functional bugs in the code, but recently, we have been able to grant a bit more attention to workflow and process tuning, so I see definite progress.

It is clear though that our initial ETA for a public beta was way too optimistic with a March release. The way it feels at the moment is that there’s still got a good 2 months to go, so I am now updating the ETA of the public beta to around May.

Place Your Bets

To keep us entertained until May, I though we could make a little game out of our bughunting quest. Whoever comes closest in guessing the final number of bugreports that will be recorded into our bugtracking system until the end of the closed beta will get a FREE UPGRADE TO FORKLIFT 2.0
*(participants of the closed beta are of course barred)

On that bombshell I am now ending this update.

Good Nights Everyone

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