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