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

henri reply to this message via the mailing list
Mon Oct 5 11:59:33 NZDT 2009


Thank you for the feedback.

To clarify, I was recently asked for a way to exclude all video files  
from a backup. I do not think I made this clear in the original email.  
The problem was that some of the video files were missing file  
extensions/suffixes. They were looking for a way to add appropriate  
extensions to the files so they could then be excluded with wild cards  
in the excludes file.

I hope this helps to clarify the reason behind this post.

>> 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.

Yes this is correct. It would be for excluding all files of a type. I  
am not suggesting that anything is actually changed in the way files  
are excluded just a possible way you can build an excludes list or  
alternatively a way to add the extensions to the files which have them  
missing.

As an example, a script could be created using the commands listed  
above, in order to setup the file extensions for the files. Then you a  
regular expression in excludes list would be able to exclude these  
video files.


>> 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.

I am not 100% on how this works. However, I believe that the data  
pulled out with the 'file' command is different to the data retrieved  
when using the 'GetFileInfo' command which retrieves the file creator  
codes. Which as I also understand things are also becoming obsolete.  
However, I could be completely wrong.


>> 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.

I agree. To clarify I am wondering if there is a file which lists UTI  
and what extension (eg.xyz) is valid for this UTI?


> 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 /.

I completely agree.


> 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?
No this is not very reliable. Although there are a number of third  
party tools available to address this issue.


> 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.

I will check this out thank you again for all your information.





More information about the lbackup-discussion mailing list