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