It's just a package maker issue, like you suspect -Jeff
On Jun 11, 11:45 pm, "ted bonkenburg" <[EMAIL PROTECTED]> wrote: > 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 > > ... > > read more » --~--~---------~--~----~------------~-------~--~----~ 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 -~----------~----~----~----~------~----~------~--~---
