![]() ![]() Windows always saves this with the other logs. Perhaps you're confusing the chkdsk bugs and maintenance message as "resource fork" corruptions? Chkdsk definitely mustn't remove any of them. These are totally normal, valid files in the NTFS POSIX namespace. Microsoft and the "closed spec" has nothing to do with this issue. Windows always saves this file under its logs. If you're using the latest release from and read the 'Known Issues' section (the Finder issue will be fixed in the coming NTFS-3G 2009.1.1 release) then please reproduce the problem and send your full CHKDSK output to s. Nobody is reporting to us such corruptions. BTW, I haven't seen anything from the original poster about whether he/she has resolved the problem yet. And we have to deal with this, because as long as Microsoft don't disclose the full specs of NTFS, there won't be any perfect NTFS support anytime soon. I only encounter this problem on disks formatted with NTFS. How do I know for sure that it's NTFS-3G? Because it never happens on my FAT32 disks. As you have said, if it was Mac OS X, it would have been consistent.īTW, from the screenshots, you can clearly see that the OP can't even access the file in Windows, so it's clear that Mac OS X is not at fault here.ģ. Photoshop uses resource forks to hold the image thumbnail, and since Leopard automatically views images in thumbnail mode, said resource fork is no longer useful. I've successfully deleted resource forks of images edited with Photoshop (image files residing on my Mac OS partition). Mac OS X doesn't lock any resource forks. With the file system fully repaired, you gain access again to said incriminating file, and thus be able to delete it. If you do a chkdsk /f, chkdsk will detect the corrupt file and will repair it so it can be accessed again (or chkdsk deletes the offending file - depends on the severity of the corruption). And once it's corrupt, neither Mac nor Windows will be able to access it. But sometimes, NTFS-3G messes up whenever Mac OS writes a resource fork file (._*) on an NTFS partition, resulting in a corrupt file (the original file itself is not affected). Most of the time, I can get rid of it without problems. With "sometimes", I really mean "sometimes". And since NTFS-3G enables write access to NTFS partitions, Mac OS creates those files there (as on other non-HFS formatted disks).Ģ. Yes, I know that "._*" files contain what would be called a resource fork on HFS+, that's why I call them resource fork files. Sorry, should have stated it more clearly, because you obviously have missed my point.ġ. _ file is just an ordinary file, as any other one. I fail to see how chkdsk could help on this and what problem you refer to be repaired. Sometimes or always? It is possible that OS X doesn't let them to remove. "Sometimes I can't get rid of it on my NTFS partition" It's a file like any other, no special handling.Ģ. NTFS-3G knows nothing about its semantic. The only problem we are aware is that it's not supported at all. "sometimes NTFS-3G has some problems with resource fork files." Please explain these sentences what you mean, what specific problems:ġ. Apple creates these files to emulate resource forks. NTFS, NTFS-3G, FAT, etc don't support resource forks. I recently got such a problem (again) with a. Just have to do a chkdsk /f first, let Windows repair the problem, and then you'll be able to delete the file. Sometimes I can't get rid of it on my NTFS partition, even from Windows. It's just that sometimes NTFS-3G has some problems with resource fork files. ![]() I use BlueHarvest to delete all resource forks on non-HFS partitions automatically. ![]() In this case, it's a resource fork for the current directory (. Nah, it's a resource fork that has no impact on the original file at all. ![]()
0 Comments
Leave a Reply. |
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |