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

[Scott Haneda]

Thanks for the clarification, comments below...

On Oct 4, 2009, at 3:59 PM, henri wrote:

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

Understood, thanks.

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

I just did some basic tests:
-rw-r--r--@ 1 haneda  staff  4028115 Aug 26 21:13 test
-rw-r--r--@ 1 haneda  staff  4028115 Aug 26 21:13 test.AVI

* files are the same, only name has been changed

$file test
	test: ISO Media, Apple QuickTime movie
$file test.AVI
	test.AVI: ISO Media, Apple QuickTime movie

So far, so good, somehow it knew, I am guessing it looks inside the  
file, first few bits, and can figure it out from there.

I think we can prove it is not meta data, with a `cp`, which can strip  
the meta data:
$cp test test-new
$file test-new
test-new: ISO Media, Apple QuickTime movie

Still somehow able to know what type of file it is.  Looks like `cp`  
now supports "Mac" files better than it used to.  I always assumed it  
was a bad way to copy files if there was resource fork data/meta data  
you wanted to preserve.

The the `cp` man page may help:
      -X    Do not copy Extended Attributes (EAs) or resource forks.

$cp -Xv test test-new
test -> test-new (added verbose mode)

$file test-new
test-new: ISO Media, Apple QuickTime movie

Running md5 on it, actually shows there is no difference, so these  
files must not have had any meta data at all to begin with:
$md5 test
	MD5 (test) =     024796da6ba5ef3ae1e2a0ea71b141ae
$md5 test-new
	MD5 (test-new) = 024796da6ba5ef3ae1e2a0ea71b141ae

Ah ha, if you look at `man file` is has a mappings file "magic" that  
is where this is all happening in.  Good to know.

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

It is a bit of a mess now, and I have a feeling people are going to  
abuse it in order to get their files to open in the app they want it  
to.  So some app that saves .txt file used to be able to remember to  
open that in for example, textedit.  Now, that will open in your set  
default text editor.  I bet developers start making up extensions,  
like "file.appname", so they can register their own UTI.  I really  
hope they do not resist this, but there is already a lot of noise on  
there about it.

I have been meaning to get to this url to read in much more detail,  
and whatever other relevant links there are within:
http://developer.apple.com/mac/library/documentation/Carbon/Conceptual/understanding_utis/understand_utis_intro/understand_utis_intro.html

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

Good, glad you understood what I meant.  UTI is going to be something  
we all need to consider for a while.  I am sort of glad, I have one  
main app I want to edit files in.  opening a .jpg to have photoshop  
take over is a nightmare, and that was happening with a lot of other  
apps.  I want to just say, ok, take all .flv files, and from now on,  
open them in VLC.  I think the .html extension was the worst, as  
sometimes I would get Safari, and others I would get TextMate.  This  
makes it a lot more uniform, and for those edge cases, you drag and  
drop to the app.

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

http://boredzo.org/blog/archives/2009-09-22/how-not-to-use-utis
That is the link I found to be the most interesting.  I think a lot of  
people are unhappy, but they are all advanced users or developers.   
End users, I do believe this is a good thing.
-- 
Scott * If you contact me off list replace talklists@ with scott@ *