Jeff Mancuso's dashboard

Rick - Sorry for our delay. I will get back to you in a day when I've taken another deep look at it. I spent a while on it and couldn't come up with a reason. I am inclined to guess it is a conflict with something in your environment, but am still looking through our code

Not yet - it's coming in the next major revision

we do support zlib compression

Yup, merging is highly needed. There simply are too many people, seemingly not willing, or too over ambitious to use the search function.
That problem is sadly as old as the internet and the first forum itself...

Glad to hear, it is being worked on.

Tyler out!

Any progress? Users VERY unhappy will long delays when navigating non-SFTPdrive-mapped drives, even "My Computer" – R Penza, on July 22, 2008 15:55

While I think this issue is low priority, I would think the compromise is to use a less literal interpretation in the icons. As with many things design related, people's preferences will be all over the place, but the new icons make no sense in relation to what ExpanDrive does.

The same designer did the Changes icon which I like. That icon works well because Changes is a diff tool so it's representing the analysis of changes in a file. When you go for a literal interpretation of a program, especially based on the product name, it's not going to end well when you call the product ExpanDrive (I'm not knocking the name, just pointing out the difficulties in representing that in an icon form). Literal interpretations of product names that work is something like Panic's Candybar. Even though it's an icon tool, the name is fun/quirky and the icon represents that.

It's understandable that you wanted to change the icon from the magnet to differentiate from Panic's Unison, but given company name Magnetk I think most people could see why you used a magnet. That said, I would think it's very difficult to proclaim how awesome the new icons are when the menu bar icon, as mentioned by someone here, looks like a stapler or a book opening up. Because I don't have ExpanDrive in my dock and I only see it at a small scale through a vertical stack, it's not as bothersome (I still find the icon awful though).

I think I suggested this once before, but one thing that would make this limitation much less painful is if ExpanDrive had user-accessible "clear cache" button. That way, I could make my changes on the server, then click the clear cache button to let ExpanDrive know that files had changed.

We took the “file truncation” complaint very seriously. We spent hours looking for the problem, and we posted a bounty on our forum for anyone that could reproduce it. But we’ve never seen file truncation ourselves, except for when the file has been edited remotely outside of ExpanDrive.

It’s been quite a while (and a number of minor releases) since we’ve had any reports of truncation as well.

Sorry that you guys don’t like the new icons.

I agree that the icon is a little more literal that is strictly necessary. We wanted something that wasn’t just a generic object. We went through a lot of ideas and sketches, and sometimes you’ve just got to pick something. I really like how it turned out.

I agree, though, that the status bar icon could use some refinement. We’ll adjust its position a bit, and (as always) we’re open to suggestions.

That makes sense, it's impossible to ensure that I have the latest version of the file if it has been edited remotely. But just to confirm, the truncating problem is fixed right? I used to open up a file and scroll to the bottom, and a third of the file would be missing. Mid-function, a huge chunk of a relatively small file would be gone. Nobody has experienced this lately, right?

We wanted to disambiguate ourselves from Panic's Unison software. When we were only making SftpDrive on windows, there wouldn't be much confusion.

http://www.panic.com/unison/

The old one looked too much like the Panic Unison icon, in our opinion. The new icon was certainly not designed by committee! Any thoughts on a compromise? – Jeff Mancuso, on July 21, 2008 17:57

Check your port. That solved it for me.

For the record, ExpanDrive still does not support files that are edited on the server. If you’re file has been edited remotely, then the only way to be certain that ExpanDrive has the most recent copy is to eject the drive and then remount it.

I know this is a severe, and sometimes painful, limitation. I’m not going to beat around the bush about it: it’s bad. It keeps me up at night. We want to fix it. We’ve prototyped fixes for it.

Unfortunately, at present we’re limited by the file system interface (MacFUSE) that we’re built on. We hope that the developers of MacFUSE will support cache flushing soon. When they do, we’ll have a beta version out very shortly afterwords. I’m sorry to say that until that time our hands are tied.

Yea, I get this too on only one of my SFTP accounts. Any progress on fixing this issue?

I strongly suspect that this is the cause. In 1.2.8 it was possible to upgrade MacFUSE on disk while leaving the old version loaded and in memory. For version 1.2.9 we’ve made this significantly harder (hopefully impossible in practice) to do. Thanks again for the report.

That sounds a lot like what we have in mind. We hope to be ready for beta testers very soon.

Something was clearly was fixed, but I'm pretty certain that one common way this problem arose for me is still an issue. Namely, if are editing a LOCAL file in Textmate, then edit it on the local computer using another editor or (most commonly for me) update it with Subversion, TextMate immediately recognizes the changes when it regains focus, and they are reflected in the editor.

If you do the same thing with a file that you load on TextMate through ExpanDrive, namely, edit the file (with vi or, presumbably, with a Subversion update, on the remote machine), TextMate does not notice that it has been changed. This means that if Subversion added material to the file, and you unknowingly save that file, the file will truncate.

The only way I know to get around this is to quit TextMate while I do the Subversion update, something that is unnecessary if I am editing the file locally. This may be an improvement--I believe (although I am not certain) that I used to also have to quit Expandrive when doing the update, but this may be fixed with the new version.

I'd just like to be able to mount my S3 account as a local disk and to be able to add/edit buckets.

I'd like to avoid having the data store in a proprietary manner making the data inaccessible via other S3 clients (i.e. Transmit).

Basically, as long as the program continues to function like it did for me with SSH, with S3, I will be extremely pleased!