Auto snapshot - bad resource fork

[peterpkcg]

Hi everyone
Reasently i found this ,for me, weird lines in the log. And for what I can tell its linked to the autosnap.
But maybe the smart brains in this forum can help me with what i can do to stop this....

To sum it up. This is what happends.

freenas autosnap.py: [tools.autosnap:42] Popen()ing: /sbin/zfs snapshot MainRaid/freenas@auto-20130214.1645-1w
freenas autosnap.py: [tools.autosnap:42] Popen()ing: /sbin/zfs get -H freenas:state MainRaid/freenas@auto-20130207.1645-1w
freenas autosnap.py: [tools.autosnap:42] Popen()ing: /sbin/zfs destroy MainRaid/freenas@auto-20130207.1645-1w
freenas afpd[41649]: getfilparams(._.DS_Store): bad resource fork
freenas last message repeated 76 times
freenas last message repeated 256 times
freenas last message repeated 1356 times
freenas last message repeated 1340 times
freenas afpd[41649]: getfilparams(._.DS_Store): bad resource fork
Feb 14 18:00:33 freenas last message repeated 75 times


And this continues.
I turned of the auto snapshots but the "last message repeated ***x times" continues to roll on.

The thing i think look weird is first of all the file name. "._.DS_Store" the mac junk would just be ".DS_Store" ?

Anyone got any ideas? I'll attach a bit more of the log here.
View attachment badfork.zip

 

[fracai]

See the part on the "bad resource fork" line that reads "afpd"? That means that it's related to the AFP server, not autosnap.py.

Now, HFS (Apple's file system) stores some data in resource forks and some in data forks. Not all file systems have the concept of multiple forks of data in a single file, while others support them but don't have a mapping set up for handling every type of data fork. Apple handles this by writing the data fork as normal and writing the resource fork along side the file with the "._" prefix.

In this case, the resource fork that is damaged is part of a .DS_Store file. These store metadata records like icon placement, folder dimensions, etc. Basically, nothing important. If you delete them, they'll be recreated.

So, I would handle this by finding and removing every .DS_Store and ._.DS_Store file on your share. The first command just lists every matching file, the second actually deletes them. I'd recommend running the first one so you can check that nothing you care about is getting caught up in the match. Note, you'll have to get friendly with the command line.

Code:

find /mnt/MainRaid -name '.*DS_Store'

Code:

find /mnt/MainRaid -name '.*DS_Store' -print -delete

It may be a good idea to disable the share first, but it's probably not necessary.

You can also tell your Mac's to not write the files to network shares using the following:

Code:

defaults write com.apple.desktopservices DSDontWriteNetworkStores true

I wouldn't worry unless you start seeing this with actual files, instead of just Finder junk.