MACSCRPT Archives

December 2008

MACSCRPT@LISTSERV.DARTMOUTH.EDU

Options: Use Monospaced Font
Show Text Part by Default
Show All Mail Headers

Message: [<< First] [< Prev] [Next >] [Last >>]
Topic: [<< First] [< Prev] [Next >] [Last >>]
Author: [<< First] [< Prev] [Next >] [Last >>]

Print Reply
Subject:
From:
"J. Stewart" <[log in to unmask]>
Reply To:
Macintosh Scripting Systems <[log in to unmask]>
Date:
Tue, 2 Dec 2008 10:21:30 -0500
Content-Type:
text/plain
Parts/Attachments:
text/plain (96 lines)
On 12/1/08 at 10:27 PM, Lois Butler <[log in to unmask]> spake thusly:

>John,
>
>PageMaker was originally made by Aldus for the Mac, where file 
>extensions really did not matter. In the late 80's they 
>expanded to the PC world where extensions are everything.
>
>You did not say what version you were running, but you can try 
>'apd' as that was the extension of the PM binary files.
>
>You can always stick your own extension on it and at the end, 
>look for any file with that extension and run your script to 
>add the Mac fileType info back in.
>
>Lloyd
>
>From: Mark Lively <[log in to unmask]>
>Date: December 1, 2008 6:41:47 PM EST
>Subject: Re: help with resource forks...
>
>
>Ah.. its not that the resource fork is missing, its that the 
>file type is being lost.  If the files have the proper 
>extension then the OS should be able to recreate it on its 
>own.  No idea of what it should be though.

This assumes you are using Mac OS X for an operating system.

If the file travels from a Mac to a Windows PC server to a Mac 
and the file isn't zipped then the resource fork IS being 
stripped assuming it had one to begin with (Satimage.osax can 
tell you). Windows has no concept of a Mac forked file and will 
split off the resource fork as a separate entity. You can see 
this using a flash drive that's in Windows format to transfer 
files from one Mac to another unzipped. Zipped (.zip, .sit, .dmg 
and several other formats) files can traverse a PC or Windows 
format flash drive or the internet with no loss of integrity 
because they are flat files.

File type code (kMDItemFSTypeCode), creator code 
(kMDItemFSCreatorCode) and file kind (kMDItemKind) are kept in 
the file's metadata and might survive an unzipped transfer 
though I've not tested it. (See: <x-man-page://mdls>) However, 
they may or may not contain data or even exist. The 
application's author decides whether or not to include that data 
by default when writing the app as they are no longer required, 
you can add some data yourself if needed. Note: if a forked file 
is transferred (as above) and the resource fork is stripped then 
99% of the time the transferred file will be made unusable 
regardless of it's file type and creator codes. The Mac knows 
what a forked file is and will balk if the resource fork is 
missing or damaged.

Given no existing file and creator codes, the file's extension 
and/or kind may be used to decide which app opens it but even 
that's not iron clad. UTI's (kMDItemContentType & 
kMDItemContentTypeTree) may also be in the mix and can change 
how a file is handled. That said, if your file doesn't have an 
extension, it's a good idea to give it one.

What really determines which app opens a file is the Launch 
Services Database according to whatever info it has about the 
file and about the various applications on the machine. There is 
a nice preference pane available that can help with determining 
which app opens a file <http://www.rubicode.com/Software/RCDefaultApp/>.

Probably the best way to trouble-shoot is to send the file in a 
zipped format and see if it opens correctly when unzipped on the 
other end, if it does, problem solved.

If not, use the mdls command in terminal on both the original 
and transferred files to see what if any differences show up in 
the metadata. Use the DefaultApp Pref.Pane to compare the setup 
on both machines and change the oddball one as necessary. Check 
the version numbers of the applications being used, are they the 
same? If not, update the oldest one. Check each file's 
permissions and ACLs (<x-man-page://acl>) to see if they've changed.

If the file still won't open correctly, you may have a corrupt 
Launch Services Database. You can delete them (the various users 
& the system all have one) and the Mac will rebuild them over 
time. This can be an excruciating pain in the butt depending on 
what you have on your Mac. It is kin to but not quite the same 
as rebuilding the Desktop on pre Mac OS X operating systems. Do 
this only as an absolutely last resort because you lose any file 
associations you've made (via get info), info on files 
downloaded from the internet, etc. Your Mac will keep you busy 
for days re-building this info and Mac OS X 10.5.x is more 
irritating about it than the older versions.

John
-- 
Any sufficiently advanced technology is indistinguishable from 
magic.  -Arthur C. Clarke

ATOM RSS1 RSS2