MacFUSE Beta 2.1.3 fixed the read/write corruptions with large NTFS block
sizes. The user, and all of us, is very happy. Thanks!
Szaka
On Fri, 19 Dec 2008, Amit Singh wrote:
> If he has the same problem with MacFUSE 1.7, then I have no idea what
> it might be. MacFUSE 1.7 has been out for a while so it's unlikely
> that nobody else ran into this.
>
> Tell him to go to System Preferences and click on the MacFUSE icon.
> It'll tell him what version he has installed. He can choose to click
> on the "Show Beta Versions" checkbox and that will enable him to
> install and use the beta releases. The latest beta that he should test
> against is 2.1.3.
>
> On Dec 18, 11:16 pm, Szabolcs Szakacsits <[email protected]> wrote:
> > It didn't help but the user is not sure if he indeed uses the beta version
> > and asked how he could check this out (what I can't reply since I never
> > used mac).
> >
> > He says problem started after upgrade from ntfs-3g-1.5012/macfuse-1.7 to
> > ntfs-3g-1.5130/macfuse-2.0.0 (iMac 2008 with Leopard 10.5.5). No downgrade
> > helps him. Problem is reproducible with the old versions too, if it is
> > indeed true that he could downgrade everything (ntfs-3g shouldn't have
> > anything around).
> >
> > Szaka
> >
> >
> >
> > On Thu, 18 Dec 2008, Amit Singh wrote:
> > > OK, let me know if 2.1.3 beta fixes the user's issue. We'll do an
> > > emergency new release of MacFUSE then.
> >
> > > On Dec 18, 11:42 am, Szabolcs Szakacsits <[email protected]> wrote:
> > > > The user has the rare f_bsize = 65536 NTFS block (cluster) size.
> > > > The default and most common is 4096 ('fsutil fsinfo ntfsinfo DRIVE:'
> > > > on Widows). I asked him to test the latest macfuse beta.
> >
> > > > NTFS-3G didn't have any change recently which could cause suddenly
> > > > corruptions.
> >
> > > > Szaka
> >
> > > > --
> > > > NTFS-3G: http://ntfs-3g.org
> >
> > > > On Thu, 18 Dec 2008, Amit Singh wrote:
> >
> > > > > If this is indeed a new bug in MacFUSE 2.0, this is pretty troubling
> > > > > and would need to be fixed soon.
> >
> > > > > Now that I think about it, I did tweak some blocksize/iosize
> > > > > parameters in the kernel. However, I looked at it again, and the
> > > > > changes do seem OK. Still, you can never tell with the Finder.
> >
> > > > > Can somebody please try to reproduce this with either sshfs or
> > > > > loopback and post the steps on how to make it happen? Hopefully this
> > > > > isn't ntfs-3g specific. I'm traveling right now and have limited
> > > > > access to debugging machines, but it'll help if I have reliable steps
> > > > > to make this happen on my machine--I can take it from there.
> >
> > > > > Amit
> >
> > > > > On Dec 17, 11:09 am, Szabolcs Szakacsits <[email protected]> wrote:
> > > > > > One NTFS-3G/MacFUSE 2.0.0 user is also reporting data corruption
> > > > > > when using
> > > > > > Finder and copying from HFS+ to NTFS. cp from the terminal is ok.
> >
> > > > > > Apparently the end of the files is missing, right after the last
> > > > > > multiply
> > > > > > of page size (4096 bytes).
> >
> > > > > > More info:http://forum.ntfs-3g.org/viewtopic.php?p=4308#4308
> >
> > > > > > On Wed, 17 Dec 2008, Andre-John Mas wrote:
> >
> > > > > > > A few questions:
> > > > > > > - what version of MacOS X?
> > > > > > > - what version and distro of Linux?
> > > > > > > - what effect does using scp from the command line give?
> > > > > > > - what about an application such as Transmit?
> >
> > > > > > > These should help us know where to focus.
> >
> > > > > > > André-John
> >
> > > > > > > On Dec 17, 12:38 pm, Chun-Yu <[email protected]> wrote:
> > > > > > > > I copied files with the Finder, and also tried running md5sum
> > > > > > > > directly
> > > > > > > > on the remote directory. Yes, the corruption can be reliably
> > > > > > > > reproduced. Also, I tried running sshfs from a linux machine
> > > > > > > > instead
> > > > > > > > of my Mac, and that works fine too. So as far as I can tell,
> > > > > > > > the
> > > > > > > > problem only exists so far on Mac -> linux.
> >
> > > > > > > > Chun-Yu
> >
> > > > > > > > On Dec 17, 11:30 am, Jeff Mancuso <[email protected]> wrote:
> >
> > > > > > > > > Chun-Yu
> > > > > > > > > What program were you using to transfer the files? Whether
> > > > > > > > > or not
> > > > > > > > > they are music files is irrelevant to the corruption
> > > > > > > > > question, or at
> > > > > > > > > least it should be. Can you consistently produce corruption
> > > > > > > > > in any
> > > > > > > > > particular series of steps?
> >
> > > > > > > > > -Jeff
> >
> > > > > > > > > On Dec 16, 9:14 pm, Chun-Yu <[email protected]> wrote:
> >
> > > > > > > > > > I was copying some music files from a machine running
> > > > > > > > > > Gentoo Linux +
> > > > > > > > > > OpenSSH 5.1p1 to my Mac with sshfs (latest MacFUSE beta),
> > > > > > > > > > and noticed
> > > > > > > > > > that the metadata tags only showed up correctly on 2 of the
> > > > > > > > > > 12 files.
> > > > > > > > > > After running md5sum on the files, I discovered that only
> > > > > > > > > > the 2 files
> > > > > > > > > > with the correct tags were copied correctly. Unmounting
> > > > > > > > > > and mounting
> > > > > > > > > > the remote directory resulted in a different (but still
> > > > > > > > > > incorrect)
> > > > > > > > > > md5sum from the first time.
> >
> > > > > > > > > > Has anyone else seen anything like this? I just tried
> > > > > > > > > > sshfs with an
> > > > > > > > > > OpenSolaris machine and another Mac, and haven't seen any
> > > > > > > > > > issues (yet).
> >
> > --
> > NTFS-3G: http://ntfs-3g.org
> >
>
--
NTFS-3G: http://ntfs-3g.org
--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups
"MacFUSE" group.
To post to this group, send email to [email protected]
To unsubscribe from this group, send email to
[email protected]
For more options, visit this group at
http://groups.google.com/group/macfuse?hl=en
-~----------~----~----~----~------~----~------~--~---
