[lbackup-discussion] Mac OS X excluding files without suffixes/extensions

[Scott Haneda]

On Oct 4, 2009, at 2:48 AM, henri <shustak at connect.homeunix.com> wrote:

> It is possible run a script to build the exclude list with various  
> information or to add appropriate extensions or suffixes to the  
> files which are missing these suffixes/extensions. The 'mdls'  
> command is able to provide you with the UTI information if spotlight  
> has built the index for the file. Specifically, you will want to use  
> the 'mdls' command to retrieve the "kMDItemContentType" which is  
> equivalent to the UTI.

>
As of Snow, with the 4 char file type code being deprecated, don't  
UTI's refer to a single file across the board? So file "worddoc" with  
no extention would have a UTI for that doc that is all inclsive of all  
UTI's for that type.

I don't see how it is possible to exclude a single file based on UTI.  
It would only be able to exclude all files of a type of UTI.

> Alternatively, if spotlight is disabled you may use the 'file'  
> command in order to extract the file type information for a file.  
> Again, this will allow you to update/build the excludes file or  
> alternvativly you will be able to use the information returned by he  
> 'file' command to update the suffix/extension of the file.

Wouldn't this only apply to files that still have creator codes? As  
file creator codes are becoming deprecated, I believe we can no longer  
rely on this meta data.

> If you are going to update a number of different kind of files. Then  
> some sort of reference in a file will probably be very useful.  
> However, there may be a reference located somewhere in the system?  
> If you know where such a map is located then please reply to this  
> thread.

I think you are touching on the huge debate around dropping creator  
codes for UTI's. Aside from manually shoving meta data into a file, I  
can not see a way to differentiate one file of one type of UTI to all  
files of that UTI type.

This mapping file would have to be path based. But that may be ok.  
Since you can move a file and it's alias will not break, that should  
mean the files location is always known.

I see the options for exclusion or inclusion being:

UTI based, where all files of a UTI type are excluded or included.  
This is dangerous as users will "change all" on a UTI and get  
unpredictable backup results.

Second is a inclusion/exclusion file manager, based purely on path.  
This falls apart if files are moved. However, rsync has worked with -- 
exlude handling a regex for a long time. Probably the best bet.

Third would be to track files in the same way aliases are resolved,  
but I'm not sure users need this granularity.

Most just want to exclude a directory, like /tmp, or cache files. But  
even excluding .cache may not be as good as simply excluding well  
known cache directories.

I'm inclined to leave this as is. File creator codes are still set,  
just not used from my understanding. Backup is usually at the least, a  
directory of some known location. At the most it is the entire /.

UTI based inclusion and exclusion seems to add a ton of area for some  
files to be missed, and others to be included that were not desired.

Has anyone ever found get info, then "change all" to be all that  
reliable?

Daring Fireball linked to a really good chat style blog post about  
UTI's. I'm mobile now and can't find it, but I would start there.
-- 
Scott
Iphone says hello.
>