tom@CITI.UMICH.EDU (08/26/87)
I agree with most of what Charlie Kim said regarding the AppleSingle and AppleDouble format. My own comments are as follows. AppleSingle: You should specify what an unused entry descriptor looks like. I suggest defining an Entry ID for "unused". AppleDouble: Putting the resource fork and the finder information in the same file is something we have considered and I believe that it will work. However, our plan was to put things at fixed offsets rather than having a map at the beginning of the file. If all the important information could be put in the first n bytes (preferably n <= 512) bytes of the Header file that would eliminate the need for multiple reads. The problem of course is the list of descriptors is variable length, there is no guarantee that it will not push the important information beyond the first n bytes of the header file. If the resource fork is empty, will there be a descriptor for it pointing to a zero length portion of the header file or no descriptor at all? If there is no descriptor, and no empty descriptors, and no space for a new descriptor it will be alot of work to add a descriptor. What if MacNFS comes across a AppleDoube file written by some other application that did not make the resource fork the last item in the headerfile? Expanding the resource fork requires alot of work. These and many other awkward cases may crop up unless the format of the header file is more rigidly defined. I am reluctant to add code to MacFNS to deal with them because they are picky format variations that may occur only ocationally and could have been avoided anyway. So, putting the finder info and resource fork in the same file will work but the format needs to be more rigid. I assume that 68xxx byte ordering in files refers to numbers such as the offsets and type numbers, not the contents of data and resource forks. I don't like having different naming conventions for different servers. This is another server dependency that MacNFS will have to keep track of. Yet, I am not sure it is possible to devise a single scheme that works for all server types. I don't know the answer to this one. From the MacNFS view and a user's view, I still prefer putting the "extra" files in a subdirectory. For the user, the directories appear less cluttered. For the software, counting the files in a directory is easier. Tom Unger University Of Michigan CITI tom@citi.umich.edu
daveb@geac.UUCP (Brown) (08/27/87)
In article <8708261841.AA19610@ucbvax.Berkeley.EDU> tom@CITI.UMICH.EDU writes: >I don't like having different naming conventions for different >servers. This is another server dependency that MacNFS will have to >keep track of. Yet, I am not sure it is possible to devise a single >scheme that works for all server types. I don't know the answer to >this one. You may consider a canonicalization procedure for names like the following (used in a C compiler for a brain-damaged linker): if name exceeds the maximum length and the its-ok flag is not set 1) from the end to the beginning delete _ characters until the length is short enough or the first character is reached (ie, don't delete leading single _'s) 2) do the same with spaces, NOT retaining leading spaces (heuristic!) 2) do the same with vowels, retaining leading vowels 3) truncate. This produces names for the linker which usually work, and are still recognizable by mere humans when using the debugger. And thats what I'm after when I want to munge a Mac filename! -- David Collier-Brown. {mnetor|yetti|utgpu}!geac!daveb Geac Computers International Inc., | Computer Science loses its 350 Steelcase Road,Markham, Ontario, | memory (if not its mind) CANADA, L3R 1B3 (416) 475-0525 x3279 | every 6 months.