home *** CD-ROM | disk | FTP | other *** search
/ NetNews Offline 2 / NetNews Offline Volume 2.iso / news / comp / sys / amiga / programmer / 703 < prev    next >
Encoding:
Internet Message Format  |  1996-08-05  |  2.1 KB
  1. Path: wbmt41.wbmt.tudelft.nl!not-for-mail
  2. From: "Marcel Offermans" <marcel@wbmt41.wbmt.tudelft.nl>
  3. Newsgroups: comp.sys.amiga.programmer
  4. Subject: Re: Protection bits
  5. Date: Wed, 10 Jan 1996 14:26:59 +0100
  6. Organization: Private TCP/IP node
  7. Message-ID: <50077646@wbmt41.wbmt.tudelft.nl>
  8. References: <john.hendrikx.44q1@grafix.xs4all.nl> <wulfraedDKy5p7.AB3@netcom.com>
  9. Reply-To: "M.F.Offermans" <M.F.Offermans@WbMT.TUDelft.NL>
  10. NNTP-Posting-Host: wb617197.wbmt.tudelft.nl
  11. X-NewsReader: IntuiNews 1.3a (7.9.95)
  12.  
  13. Hello Dennis,
  14.  
  15.  > In article <john.hendrikx.44q1@grafix.xs4all.nl>
  16.  > john.hendrikx@grafix.xs4all.nl (John Hendrikx) writes:
  17.  
  18.  >> When I come to think of it this doesn't seem all that hard to do and it
  19.  >> would probably not even slow down the filesystem. I mean, taking a peek
  20.  >> at the first 512 bytes as it is written shouldn't be that hard. The only
  21.  >> trouble is that 512 bytes might not be sufficient to make a FileID...
  22.  
  23.  > But that basically would be the same as having the contents of an .info
  24.  > file as the first block of EVERY file...  Which I think is the basic
  25.  > idea on the Mac (I don't fully understand the "data" and "resource"
  26.  > forks but if the "resource" fork is a block at the start of the file
  27.  > that IDs the file type and the program that generated it...).  I,
  28.  > personally, prefer files to be PURE files; not some hybrid that
  29.  > requires tricks to transfer to other users.
  30.  
  31. Either you misunderstood John or I did. I don't think John meant that the
  32. first 512 bytes should be made into a file ID, he simply suggested that
  33. looking at the first 512 bytes of any file should be enough to identify the
  34. file (in most cases).
  35.  
  36. The file type could then be stored somewhere in the FileInfoBlock, for
  37. example.
  38.  
  39. If we expand this idea a little further, it could be the start of a more
  40. object oriented view on files. For each type, you could define a couple of
  41. actions, like "view", "edit", "print" and associate them to your favourite
  42. picture viewer, word processor, etc. Now if this can be merged with the
  43. datatypes features of the OS, it would make a very nice extension.
  44.  
  45. Greetings, Marcel
  46.  
  47.