See inline below. On Wed, Jun 11, 2008 at 11:12 AM, Jeff Mancuso <[EMAIL PROTECTED]> wrote: > > > > 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. >
Can you describe your fix in more detail? I'm also very concerned with the way you are distributing MacFUSE and the problems it is likely to cause for others. If you distribute MacFUSE with your product then you should install the "MacFUSE Core.pkg" as-is rather than modifying it. It will handle upgrades properly and refrain from downgrading if the user has already installed a newer version. In addition to the issues that Amit pointed out above, the MacFUSE packages that you are including are modified to remove their preflight, VolumeCheck, and InstallationCheck scripts. The package that you install also has a different CFBundleIdentifier and CFBundleShortVersionString. I think these problems are most likely due to issues with PackageMaker, but I want to make sure that you have a good fix in place. Also, does your fix clean up prior installs that have the incorrect name and Info.plist values from /Library/Receipts? ted > > > >> 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 -~----------~----~----~----~------~----~------~--~---
