jjoshua@remus.rutgers.edu (J. Joshua) (11/29/90)
Does the NeXT file system support Forks a-la-Macintosh? In other words, where are the file's attributes stored? Are they contained in the actual file (and are invisible to you and me) or are they located somewhere else. Thanks, JOn. -- ________ | | This Messsage A Service By: | | Closed Captioned Jon Joshua | | For the Hearing Impaired jjoshua@remus.rutgers.edu `----. .-' |/ #include <whittyComment.h>
mdixon@parc.xerox.com (Mike Dixon) (11/30/90)
Does the NeXT file system support Forks a-la-Macintosh? In other
words, where are the file's attributes stored? Are they contained in
the actual file (and are invisible to you and me) or are they located
somewhere else.
no, NeXT files don't have forks. standard unix file attributes (e.g.
creation & modification dates, length) are stored separately from the
file contents; they're available through a set of system calls.
NeXT-specific things like a directory's default view and a file icon's
position in its parent's browser are stored in horrible little '.places'
files scattered through the file system. (i'm told that 2.0 is much
better about not creating these egregiously.)
the mac 'file type' and 'file owner' properties have no equivalent on
the NeXT; the workspace manager fakes it by using extensions on the file
name. (e.g. foo.rtf, foo.frame, foo.ma)
--
.mike.glang@Autodesk.COM (Gary Lang) (11/30/90)
>no, NeXT files don't have forks. standard unix file attributes (e.g. >creation & modification dates, length) are stored separately from the >file contents; they're available through a set of system calls. Ah but this isn't standard Unix, it's Mach, and it's much better about this sort of thing. Icons, interface builder objects, sounds and the like are stored in sections of named segments of an object file. You can get access to these pieces of data through low-level mach calls or more likely through appkit calls that know about the most interesting kinds of these objects (windows, IB classes, icons, etc.). - g
jacob@gore.com (Jacob Gore) (12/01/90)
/ comp.sys.next / jjoshua@remus.rutgers.edu (J. Joshua) / Nov 28, 1990 / > where are the file's attributes stored? Are they contained in > the actual file (and are invisible to you and me) or are they located > somewhere else. Data files in Unix are typeless by design. Each is just a finite stream of bytes. However, type information is often helpful, so it is represented by programs and applications in two ways: 1. The filename "extension" (the last dot in the filename and all the characters that follow it). For example, ".c" for C files, ".m" for Objective-C files, ".wn" for WriteNow documents. The Unix file system treats the whole filename as one unit. NeXT Workspace Manager, however, uses the file extension to decide what application will process a file if you double-click on that file's icon. 2. The "magic number". This is, generally, the first few bytes of the file. (Not all files will have something meaningful there.) For example, a Mach-O executable will have the number 'feedface' (hexadecimal) there; shell scripts may have "#!" as the first two bytes to tell the loader that the filename that follows them is the program to load for execution of the script (e.g., "#!/bin/csh -b"). An archive will have the text "!<arch>\n" there ("\n" is a newline). Magic numbers are not used by the Workspace Manager in 1.0 (as far as I can tell), but the loader uses them when the file is executed as a program, and applications are free to use them. The 'file' command, which tries to determine the type of a file, also tends to use it... I don't know if the version in NeXT 1.0 does, and it is quite broken in 1.0 anyway (produces a segmentation fault on NeXTstep applications, which are quite common on the NeXT:-). By the way, just because something is stored in a data file, doesn't at all mean that it's "invisible to you and me". It's still just a data file, so you can pull it into Emacs -- I'd suggest you do it read-only (C-x C-r), unless you understand the file's format and are skilled at editing octal representations of bytes -- and look at it all you want. Here is the first four bytes of an application (converted to ASCII for posting -- in Emacs, each "\..." is one byte, represented in octal): \376\355\372\316 or, in hexadecimal: fe ed fa ce Or, you can just do a hex dump: jacob@blackbox> od -x /NextApps/Edit | head -2 0000000 feed face 0000 0006 0000 0001 0000 0002 0000020 0000 000b 0000 07ac 0000 0001 0000 0001 jacob@blackbox> od -x /bin/od | head -1 0000000 feed face 0000 0006 0000 0001 0000 0002 jacob@blackbox> od -h /usr/shlib/libsys_s.B.shlib | head -1 0000000 feed face 0000 0006 0000 0001 0000 0003 jacob@blackbox> Or a character dump: jacob@blackbox> od -c /lib/libc.a | head -1 0000000 ! < a r c h > \n _ _ . S Y M D E jacob@blackbox> Jacob -- Jacob Gore Jacob@Gore.Com boulder!gore!jacob
moose@svc.portal.com (12/01/90)
In article <975@autodesk.COM> glang@Autodesk.COM (Gary Lang) writes: >Ah but this isn't standard Unix, it's Mach, and it's much better >about this sort of thing. > >Icons, interface builder objects, sounds and the like are stored >in sections of named segments of an object file. You can get access >to these pieces of data through low-level mach calls or more likely >through appkit calls that know about the most interesting kinds >of these objects (windows, IB classes, icons, etc.). Could one put named segments in non-object files? In other words, could I have a save document for my application that uses these segments? Such as Write Now putting the graphics into the same file as the text, just a different segment. Currently they use file packages. -- Michael Rutman | moose@svc.portal.com Cubist | makes me a NeXT programmer Software Ventures | For Your Eyes Only Public Key
wiml@milton.u.washington.edu (William Lewis) (12/01/90)
In article <975@autodesk.COM> glang@Autodesk.COM (Gary Lang) writes: >>no, NeXT files don't have forks. standard unix file attributes (e.g. >>creation & modification dates, length) are stored separately from the >>file contents; they're available through a set of system calls. > >Icons, interface builder objects, sounds and the like are stored >in sections of named segments of an object file. You can get access >to these pieces of data through low-level mach calls or more likely >through appkit calls that know about the most interesting kinds >of these objects (windows, IB classes, icons, etc.). Actually, so far as I know, Mach doesn't care about the segment/section structure of Mach-O files, except when loading them. A Mach-O file is just a normal, 'flat' Unix byte stream; it simply has an agreed-upon format for putting in sections and segments. The relevant *library* calls (not Mach functions) are described in <sys/loader.h>, I think. The format is simple enough that it's also easy just to read in a Mach-O file and parse it 'by hand'. There's a program, fsectbyname, on the archives that does this sort of thing. It even has source. -- wiml@milton.acs.washington.edu Seattle, Washington (William Lewis) | 47 41' 15" N 122 42' 58" W "These 2 cents will cost the net thousands upon thousands of dollars to send everywhere. Are you sure you want to do this?"
scott@mcs-server.gac.edu (Scott Hess) (12/01/90)
In article <1990Dec1.021843.5148@svc.portal.com> moose@svc.portal.com writes: In article <975@autodesk.COM> glang@Autodesk.COM (Gary Lang) writes: >Icons, interface builder objects, sounds and the like are stored >in sections of named segments of an object file. You can get access >to these pieces of data through low-level mach calls or more likely >through appkit calls that know about the most interesting kinds >of these objects (windows, IB classes, icons, etc.). Could one put named segments in non-object files? In other words, could I have a save document for my application that uses these segments? Such as Write Now putting the graphics into the same file as the text, just a different segment. Currently they use file packages. Hmm. No reason why not. Just pretend it's an object file (not an executable), and do everything you need to it (for instance, you'd have a _TIFF section, _EPS section, maybe even and _OBJC section if your program support loadable modules, and this file needs one). All that's needed is a decent library to access this stuff, and that's _supposed_ to be in 2.0 (I can't say, I've not looked). I think it'd be nicer than a file package, because you can then moved everything about atomically. It would _really_ be nice if everything stayed in semi-standard places. I've been thinking of writing a MACH-O editor, which would allow the user to edit the MACH-O file, and always putting .tiff files in the _TIFF segment would really be nice for usability. Then again, the MACH-O format is just that - a format. There's nothing really special about it, you can (and must) still read it as a regular Unix file. You just treat the info differently depending on what you've already read in. So you could just define your own new file type (as it appears FrameMaker has, since all it's data is held in a single file). -- scott hess scott@gac.edu Independent NeXT Developer (Stuart) GAC Undergrad (Horrid. Simply Horrid. I mean the work!) <I still speak for nobody>