Dave Coder wrote:
>Any list mode analysis program that reads FCS files (in the various
>permutations and implementations of FCS--a nice standard that provides so
>many choices) should read CellQuest files. IF AND ONLY IF the files are
>transferred as binary (NOT Mac binary) to strip the resource fork and
>transfer only the data fork. (The multiple part file type--a curiosity of
>the Mac OS--makes bona fide Mac files by definition incompatible with the
>FCS specification in that a file does not start with the characters FCS.
>The solution to the problem is simple as I outlined above.)
>Dave Coder
>dcoder@u.washington.edu
The parenthetical remarks are a bit of a slur on Macintoshes, Dave is
confusing his file types:
Bona fide mac files don't need to have a resource fork, and indeed most
data file types don't use one ( It would appear that B-D append an empty
[redundant] resource fork to their data files, but that doesn't matter).
The two forks are actually separate files which are accessed using
different OS/Toolbox managers, (although the Finder handles them as one
file,) if you open a document on a mac, you get the data fork/file - the
resource fork/file (if it exists) doesn't get in the way.
This "multiple part file type" allows you to easily separate invariant data
and code from application-written data all in one file, allowing
self-reading data files (which have a text reading application stuffed into
their resource fork) and application files that can contain their own fixed
data (eg font and menu descriptions-"resources") as well as code in their
resource forks and variable data (such as serial numbers or preferences)
in their data forks. Which means you can move a lot of information around
by dragging one icon, you don't need to move a .exe., a .bin, AND a .dat or
whatever.
MacBinary files are a different species, they are a way of encapsulating
the data and resource forks (if extant) along with Finder information (such
as the file's creator, type, position in window, parent directory etc),
which governs the file's appearance. The purpose of MacBinary is to allow
you to transfer mac files to servers not aware of the mac's file system,
and back again to a mac, without losing anything in the process. This
requires appropriate encoding and decoding at each end. Unless they have
translators, macintosh programs can't read or write MacBinary files, and
don't need to. The order of data storage in MacBinary is; header,
datafork, resource fork.
MacBinary files, by definition, are incompatible with the FCS file format,
but so are .zip files. Bona fide Mac files have no problem.
On the FCS side, are there any programs that do cover all of the
permutations of any version? Are there any that actually conform yet? Are
there any plans to certify/verify programs' compliance?
Ray
Ray Hicks
________________________________________________________________________
|University of Cambridge |Tel 01223 330149 |
|Department of Medicine |Fax 01223 336846 |
|Level 5, Addenbrookes Hospital |e-mail <rh208@cus.cam.ac.uk> |
|Hills Road Cambridge |Web http://facsmac.med.cam.ac.uk |
|CB2 |ftp server ftp://131.111.80.78 |
|UK | |
|_________________________________|_____________________________________|
This archive was generated by hypermail 2b29 : Wed Apr 03 2002 - 11:49:53 EST