 |
 |
 |
 |
Once a Mac binary file has been transferred as text, it's hosed as far as
ever again reading it in CellQuest. Two reasons: 1. there are carriage
returns interspersed in the data portion of the file 2. the Mac file resource
is missing. (Footnote about the data file showing a MS Word file icon: Fetch
allows you set the option for the type of text file when you export a file as
text; MS Word is apparently the default selection.) Attempts to transfer it
back to the Mac using binary mode are doomed because a binary transfer does
an exact copy of the original--warts and all in this case. Stripping <CR>'s,
as Joe Trotter suggested, will probably restore it. (And, of course, never
ever erase the original data files until you have a safe archive.)
The Macintosh file system uses files that have two parts: a data fork and a
resource fork. The data fork contains, well, the data--the file's contents.
The resource fork tells the Mac operating system various things about the
file: What kind of file it is, what application created it, etc. The resource
fork is often needed such that a Mac application can recognize compatible
files. For example, CellQuest v. 1.2 will not read a flow data file in the
FCS format; it needs the Mac resource fork to tell it that the file is a
CellQuest file. (As an aside, the FCS specification may need a modification
for Mac OS files because the standard specifies that the first three
characters in the binary file must be FCS. Hey, Larry! Got that?)
When transferring from the Mac to another computer, Fetch gives you the
choice of transfer mode for binary files (and remember, FCS files are binary
not text despite the fact that they have an ASCII portion at the start of the
file): Mac Binary, Raw Data, BinHex, Apple Single. If you are transferring
the files to another Macintosh, then MacBinary is the one of choice because
it will transfer both parts of the Mac file including the data and resource
forks. If you are transferring to any other operating system, then Raw Data
is the the choice to use. This is important because you want just the data
fork; the resource fork which precedes the data fork will make it unreadable
since it no longer adheres to the FCS file specification.
Dave Coder
dcoder@u.washington.edu
|
|
|
|