On Jun 11, 1:28 am, Amit Singh <[EMAIL PROTECTED]> wrote:
> 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.)
>

Fair enough, I do agree with you here.

> I plan to do a new release of MacFUSE shortly after WWDC.
>

Great!

> 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
>

Alright - we'll check that out. We might release a nightly/
experimental build that integrates SVN head of MacFUSE for our users
to test out against ExpanDrive specifically, along with point them at
a place where they can alleviate their problems in the short term.


> 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.
>


The was an oversight on our part, a fix is now in place.




> 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
-~----------~----~----~----~------~----~------~--~---

Reply via email to