I am still able to reproduce the corruption quite reliably, even after switching to the 32 bit kernel. I have finally gotten around to re-testing this corruption issue I was seeing previously, as mentioned above. If the corruption is on the data level and caused by OSXFUSE we would most likely see similar issues with other file systems, too. the file system itself is fine, evidenced by running chkdsk in Windows), then OSXFUSE could be to blame (not necessarily, but it's at least possible).
In general, data corruption errors can be on the file data level or one the file system level. Would be much more likely than random corruptions written out to disk. With regard to maintaining file system integrity is if its libfuseĬorrupted the NTFS-3G process memory space, but in that case a crash The only way OSXFUSE could influence NTFS-3G's operation Level and in that case, NTFS-3G itself is most likely to blame rather In this case it's not on the file data level but on the file system Then OSXFUSE could be to blame (not necessarily, but it's at least theįile system itself is fine, evidenced by running chkdsk in Windows), In general, data corruption errors can be on the fileĭata level or one the file system level. > Erik, what is your opinion on this? Have you heard of similar issues? OSXFUSE just passes file system operations along. > But just to make this clear: OSXFUSE does not write to the physical drive. To track this issue down you could boot Snow Leopard in 32 bit kernel mode and "try" to get some data corruption errors using OSXFUSE and NTFS-3g. > I wonder if those corruption errors are linked to the 64 bit kernel code or OSXFUSE/NTFS-3G in general. Of note, I never saw disk corruption when using MacFUSE and this same NTFS-3g build, under the 32 bit kernel in Snow Leopard.
0 kommentar(er)
