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