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

[henri]

Hi,

Thank you very much for great information and research. Just starting  
to look at some of the links. So far they look like great resources.

Thanks again.


> Thanks for the clarification, comments below...
>
>> 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.