I would *strongly* discourage you from distributing your own builds of MacFUSE. It's a bad idea in the long run. (See my postscript note below.)
I plan to do a new release of MacFUSE shortly after WWDC. Yes, I see that you really want this issue to be fixed for your users. You don't need to roll out your own MacFUSE for that. This particular issue can also be fixed by simply using the "allow_root" mount-time option. As a side effect of using allow_root, the volume will become accessible to Spotlight and fseventsd. This is not the default behavior (although some people may actually desire this.) If your users want the default behavior of denying access to Spotlight and fseventsd, they can do the following: * Create an empty file called .metadata_never_index at the top level of the volume * Create a .fsevents/ directory at the top of the volume * Create an empty file called no_log in the .fsevents/ directory Amit PS: Do realize that MacFUSE is used by many developers. Unlike typical libraries/bundles, MacFUSE is a system-wide global shared resource because there is a kernel extension involved. What happens if several vendors, each with their own priorities and schedules, begin distributing their own differently-compiled MacFUSE binaries? I also see issues with how ExpanDrive is (re)packaging MacFUSE. If I remember correctly, ExpanDrive is changing the package name that gets installed and subsequently recorded in /Library/Receipts. However, the package contents get installed at the same location as in the official MacFUSE package. This means that if the user subsequently installs MacFUSE from another source, it could overwrite ExpanDrive's installation. Worse still, ExpanDrive will overwrite the official MacFUSE installation, even if the latter happens to be newer. *Not good*. Moreover, the uninstall-macfuse-core.sh script, which ExpanDrive is installing as-is, will not clean up its own renamed package receipt. On Jun 11, 12:18 am, Jeff Mancuso <[EMAIL PROTECTED]> wrote: > Preliminary testing on 10.5.3 and 10.5.4 indicates that this fixes the > issue > Thanks! > > I notice the patch is rather small in size, and seems to be minor. > Can you imagine any obvious stability issues this patch would cause if > we applied it to the 1.5.1 release? > > We really would like to roll out this fix ASAP to our customers, > because it's a real show stopper for a variety of use cases > > -Jeff > > On Jun 10, 2:04 am, Amit Singh <[EMAIL PROTECTED]> wrote: > > > Can you try the latest svn tree (revision 969 at the time of this > > writing, or newer) and see if things are any better? > > > Amit > > > On Jun 7, 11:45 am, Amit Singh <[EMAIL PROTECTED]> wrote: > > > > Well then, looks like lots of people are having these issues on > > > several file system types. > > > > The "workaround" is lousy. You guys should get on Apple's case (well, > > > to the extent it's possible to do so with Apple) to figure out a > > > proper fix for this issue. > > > > When I get a chance, I'll look into it some more to see if I can do > > > something to fix this within MacFUSE. > > > > Amit > > > > On Jun 7, 8:11 am, Jeff Mancuso <[EMAIL PROTECTED]> wrote: > > > > > Preliminary testing indicates the Save As workaround fixes things with > > > > this test case on 10.5.3 & 10.5.4 > > > > > -Jeff > > > > > On Jun 7, 4:59 am, Amit Singh <[EMAIL PROTECTED]> wrote: > > > > > > Hmm, also see: > > > > > >http://discussions.apple.com/thread.jspa?messageID=7280520 > > > > > > In that thread, users are saying that if they always use "Save > > > > > As" (and choose to Replace the file), things work. If they simply do > > > > > "Save", it's broken like in your case. > > > > > > Can you try the Save As "workaround" and see if it's the same > > > > > situation as these folks? > > > > > > Amit > > > > > > On Jun 6, 11:54 pm, Amit Singh <[EMAIL PROTECTED]> wrote: > > > > > > > That's a very good bug report--thanks; I can reproduce your issues. > > > > > > > I'll look into it when I get a chance. Looks very similar to the > > > > > > following issue people seem to be having with NFS (read all the > > > > > > messages in that thread): > > > > > > >http://discussions.apple.com/thread.jspa?threadID=1367342 > > > > > > > Amit > > > > > > > On Jun 6, 10:33 pm, Jeff Mancuso <[EMAIL PROTECTED]> wrote: > > > > > > > > It seems that OS X 10.5.3 has introduced some problems for MacFUSE > > > > > > > > We first noticed issues saving and then re-opening files in > > > > > > > ExpanDrive > > > > > > > that were saved using TextEdit/CSSEdit/SubEthaEdit. We were able > > > > > > > to > > > > > > > save a file, but not re-open it without a "-43" error issued by > > > > > > > Finder > > > > > > > [which seemed odd]. More interesting, our FS wasn't itself > > > > > > > returning > > > > > > > that code at any point. > > > > > > > > The only common thing we noticed was the style of atomic saves for > > > > > > > these particular applications. They all perform their atomic > > > > > > > saves by > > > > > > > creating a temporary file in a folder structure such as: > > > > > > > > .TemporaryItems/folder.501/TemporaryItems/(A document being saved > > > > > > > by > > > > > > > Text Edit) > > > > > > > > While I'm sure the naming structure isn't the precise issue, > > > > > > > TextMate/ > > > > > > > EMACS, with similar styles of save&rename atomic saves exhibit no > > > > > > > problem. Perhaps the only major difference is that the file is > > > > > > > renamed > > > > > > > from a sub folder into a parent folder. > > > > > > > > We first attributed this issue to our use of the 'local' flag, > > > > > > > because > > > > > > > turning off allowed the file to re-open. However, upon further > > > > > > > investigation, it seems this problem runs deeper. Further testing > > > > > > > with > > > > > > > the local flag off, showed us that after multiple save attempts, > > > > > > > the > > > > > > > data is not being saved correctly. > > > > > > > > I submit the following test using LoopbackFS, running against > > > > > > > MacFUSE > > > > > > > 1.5 on 10.5.3. I've also tested this example against MacFUSE > > > > > > > trunk, > > > > > > > and I've verified that the 10.5.4 developer seed does not fix the > > > > > > > issue. This test works correctly on 10.5.2, for us. > > > > > > > > In addition, we can reproduce similar behavior using ExpanDrive, > > > > > > > SSHFS, and some python based passthrough filesystems we wrote for > > > > > > > testing > > > > > > > > 1.) Mount an empty directory using LoopbackFS [no local flag, > > > > > > > vanilla > > > > > > > release build of MacFUSE 1.5 from SVN] > > > > > > > > 2.) Open text edit and make a file with the contents > > > > > > > 1 > > > > > > > 2 > > > > > > > 3 > > > > > > > > 3.) Save contents, close text edit > > > > > > > > 4.) Re-open and verify contents > > > > > > > > 5.) modify contents: > > > > > > > a > > > > > > > 2 > > > > > > > 3 > > > > > > > > save > > > > > > > > 6.) modify contents: > > > > > > > a > > > > > > > b > > > > > > > 3 > > > > > > > > save, quit text edit > > > > > > > > 7.) re-open file with text edit, contents incorrectly read > > > > > > > a > > > > > > > 2 > > > > > > > 3 > > > > > > > [results of step 5] > > > > > > > > Further notes: > > > > > > > > Conole.app also prints a message from TextEdit saying > > > > > > > "The temporary directory at > > > > > > > '/Volumes/loop/.TemporaryItems/folder.501/ > > > > > > > TemporaryItems/(A document being saved by Text Edit)' could not be > > > > > > > deleted > > > > > > > > Our testing indicates that a fuse operation for unlink on the > > > > > > > temporary file in this directory is never making it up to user > > > > > > > mode. > > > > > > > In addition, as one might expect, weirder things happen, too, if > > > > > > > the > > > > > > > local flag is turned on. I only mention it because no > > > > > > > [intermittent > > > > > > > 'weird'] issues appear in Tiger or 10.5.2 even with the local flag > > > > > > > enabled for a mount. > > > > > > > > Another [probably related] bug. We first noticed this last week > > > > > > > with > > > > > > > 10.5.3 and ExpanDrive, but I am able to replicate it with > > > > > > > LoopbackFS > > > > > > > > 1. Setup loopback FS to point to an empty directory [or a > > > > > > > directory > > > > > > > with a few files in it, no folders] > > > > > > > 2. create a folder named a, move a file into it > > > > > > > 3. view contents of newly created folder a, verify the newly > > > > > > > inserted > > > > > > > file > > > > > > > 4. create a folder named b > > > > > > > 5. view contents of folder b, somehow they mysteriously have the > > > > > > > contents of folder A already inside them. > > > > > > > > I've posted a video of this > > > > > > > happening:http://www.magnetk.com/expandrive/bug2.mov > > > > > > > > We'd love to help solve this in whatever way we can. My guess is > > > > > > > that > > > > > > > it is a bug Apple somehow introduced, but it's possible that > > > > > > > 10.5.3 > > > > > > > has revealed latent issues with MacFUSE. Any thoughts? > > > > > > > > Thanks --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "macfuse-devel" group. To post to this group, send email to macfuse-devel@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/macfuse-devel?hl=en -~----------~----~----~----~------~----~------~--~---
