Jump to content
We're Hiring! Full Stack Developer ×

Constant "duplicate object" log errors


Auggie

Recommended Posts

This has been a nagging issue with me since v4.x and continues into v5 beta's, but what the heck are these unending "duplicate object" errors that clog the syslog constantly?

 

unRAID apparently does not like any of OS X's "invisible" (in OS X Finder) .DS_Store files which contain user customized folder attributes. and incessantly flags them in the syslog (snippet attached).  The problem is that there is no real error that I can identify with these files so these dubious "errors" clog up the syslog, making it difficult to locate real errors.

 

FEATURE REQUEST:  Unless there is a truly valid error involved here, can we not have unRAID "ignore" or fix the "bug" in which unRAID incorrectly marks OS X meta-data files as "duplicate objects?"


I may now be understanding a little more of the errors specifically involving the .DS_Store and ._Icon (which contains a user customized folder that was assigned) "duplicate errors" when identically named folders across different drives are virtually combined into defined User Shares as unRAID would see the same .DS_Store file (and ._Icon file if customized icons were assigned to these folders) across the different, identically named folders.  Perhaps then to provide an "option" for unRAID to ignore these specific file names when checking for "duplicate objects" as it maintains virtual user shares.

syslog-2011-09-21-snippet.txt

Link to comment

Presently, due to how unRAID combines same-name folders across different drives when creating virtual user shares, this is it's "normal" behavior as it comes across Mac OS X specific meta-data files for all folders and flags them via the syslog to indicate it found "duplicate" objects (files) as it's comprising the virtual user share.

 

You can't delete these .DS_Store and ._Icon files if you still access the folders directly through their actual disk being mounted on an OS X machine as OS X will recreate them.

 

Which is why I propose a feature request to allow users the option to have unRAID ignore specifically .DS_Store and ._Icon files to alleviate the "congested" and constant syslog entries related to these files for unRAID servers accessed by OS X machines.

 

If you only access the affected folders via the virtual user shares only, then you could locate and delete all the .DS_Store and ._Icon files of the folders (only) via FTP after you ensure all drives are unmounted first, then from that point forward you must always mount just the virtual user share.

Link to comment
  • 2 weeks later...

There is a pref pane for OS X, called blue Harvest, that supposedly deals with this problem. It will remove, and stop creating ._ files, when OS X accesses non Mac filesystems. I dl'd it yesterday after noticing a ton of ghost ._ files after copying a fubared HD, so no experience with it yet. May be worth checking out.

Link to comment

Yes, I use this tool for drives that primarily are used with Windows machines.

 

However, my unRAID is used under primarily OS X, so these meta data files are a necessary "evil" that can not be continuously deleted, which not only degrades performance of the unRAID machine, but OS X will simply recreate them again.

 

Hence my feature request for unRAID to provide a user option to disregard monitoring specific files (.DS_Store and ._Icon files only).

Link to comment

This must happen if you access the content via the disk share. The duplicate files can't be created via the user share so you must be also using the disk shares.

 

Delete the duplicates and then only access the content via the user share. Or else, find a way to combine the contents of the different disks on the Mac and only use the disk shares.

 

Peter

 

Link to comment

This must happen if you access the content via the disk share. The duplicate files can't be created via the user share so you must be also using the disk shares.

 

Delete the duplicates and then only access the content via the user share. Or else, find a way to combine the contents of the different disks on the Mac and only use the disk shares.

 

Peter

 

 

Yes, I understand the whole process.

 

I do not like the algorithm that unRAID uses for "split level" as it doesn't put associated files that I add later on the exact same disk where the original folder resides.  Nor do I like the Allocation methodology used for my purposes.

 

And since I am upgrading each 2TB drive to 3TB as I run out of space, I need to control exactly where files are placed.

 

Hence, my need to perform most of my file management through the disks directly.

Link to comment

Archived

This topic is now archived and is closed to further replies.

×
×
  • Create New...