Loading Profile...
it caches!
expandrive caches, so when i create a new file or folder in for example transmit, expandrive does not update .... pretty useless like this although the concept of your program is awesome
2
people have this problem
I have this problem, too!
Tell me when someone solves it.
The more people who report this problem, the more it gets noticed.
The more people who report this problem, the more it gets noticed.
The best solution from the company
-
This behavior will be greatly improved very soon.
ExpanDrive uses the MacFUSE to create a file system on OS X. OS X itself automatically caches a lot of file data in the kernel, and in the past it was impossible to tell OS X to update its cache through MacFUSE. As a result, when a file or directory was modified “remotely” (ie, not through ExpanDrive), we couldn’t tell OS X to update its cache. Sometimes it would take up to 5 minutes for OS X to decide to refresh its data on its own. Not good, I know.
This past Monday (12/8/2008), MacFUSE 2.0 was released with dramatically improved kernel caching. We’ve been testing against the developer’s release of MacFUSE for some time now, and it looks awesome. We’re doing a thorough audit of our MacFUSE install / update system, and we’re going to push an update with the newest version of MacFUSE. Probably early next week.
If you don’t want to wait for our release, then you can upgrade MacFUSE on your own by downloading it directly from Google. It’s completely painless, and you’ll see the caching improvements as soon as it’s installed.
I’m excited
The company and 2 other people say
this solves the problem
-
Inappropriate?This behavior will be greatly improved very soon.
ExpanDrive uses the MacFUSE to create a file system on OS X. OS X itself automatically caches a lot of file data in the kernel, and in the past it was impossible to tell OS X to update its cache through MacFUSE. As a result, when a file or directory was modified “remotely” (ie, not through ExpanDrive), we couldn’t tell OS X to update its cache. Sometimes it would take up to 5 minutes for OS X to decide to refresh its data on its own. Not good, I know.
This past Monday (12/8/2008), MacFUSE 2.0 was released with dramatically improved kernel caching. We’ve been testing against the developer’s release of MacFUSE for some time now, and it looks awesome. We’re doing a thorough audit of our MacFUSE install / update system, and we’re going to push an update with the newest version of MacFUSE. Probably early next week.
If you don’t want to wait for our release, then you can upgrade MacFUSE on your own by downloading it directly from Google. It’s completely painless, and you’ll see the caching improvements as soon as it’s installed.
I’m excited
The company and 2 other people say
this solves the problem
-
Inappropriate?In 1.3.3b7, hw much time must pass before MacFUSE will invalidate the local cache?
Is there any way to manually disable caching? Sometimes I'm working with others remotely and doing tag-team edits. Even a cache window as small as 1 minute would be painful.
I’m sad
-
Inappropriate?Ben,
MacFUSE 2.0 will update the kernel cache any time it detects that a file’s size or modtime has changed. ExpanDrive will notice that a file’s size or modtime has changed, and report the change to MacFUSE whenever it is asked by a program to list the contents of a directory, for that stats of a file, or to open a file handle.
Realize that we have some unavoidable trade-offs here. The more aggressive we are about detecting remote changes, the more often we have to poll the server for data rather than use a local copy, the less responsive ExpanDrive will be.
The we we do thing now, with MacFUSE 2.0, multiple users on the same file over ExpanDrive should be very similar to multiple users on the same file on a local machine. This is about as good as anyone can do. Whether or not this is safe depends on the programs you’re using, and how seriously they handle the possibility of a file changing on disk.
For example, imagine a hypothetical program “WidgetWrite”. When you ask WidgetWrite to open a file, it might open it, read it, save a copy to a buffer for you to edit, and close the file handle. While you think you’re editing “the file”, you might actually just be editing WidgetWrite’s copy of that file in memory. If the file changes on disk, and WidgetWrite doesn’t periodically check the filesystem to see if the file has changed, then there’s nothing ExpanDrive or anyone else can do to make WidgetWrite detect those changes. The program has to ask. With ExpanDrive 1.3.3b7 an on, if the program asks, we’re going to tell it.
I’m doing the best I can.
-
Inappropriate?Ok I've upgraded to the latest beta 1.3.3b7 and the fix has in my opinion made this much much worse.
Now BBEdit sits and spins like TextMate used to. It appears that MacFUSE 2.0's cache invalidation has fixed the multiple user problem but introduced a worse problem: everything freezes too often while MacFUSE refreshes the mount.
I’m sad
-
Inappropriate?I am noticing this same effect. Any way to change how often the program checks for changes?
EMPLOYEE
