home *** CD-ROM | disk | FTP | other *** search
/ NetNews Offline 2 / NetNews Offline Volume 2.iso / news / comp / sys / amiga / programmer / 1005 < prev    next >
Encoding:
Text File  |  1996-08-05  |  3.2 KB  |  75 lines
  1. Path: news.mountain.net!usenet
  2. From: gene_heskett@wvlink.mpl.com (Gene Heskett)
  3. Newsgroups: comp.sys.amiga.programmer
  4. Subject: Re: Protection bits
  5. Date: 13 Jan 96 17:22:17 +0500
  6. Organization: MountainNet, Inc. Morgantown WV 800.444.1458
  7. Message-ID: <2902.6586T1042T898@wvlink.mpl.com>
  8. References: <DKyoqJ.Lnu@csc.liv.ac.uk>
  9. NNTP-Posting-Host: slip5.mpl.com
  10. X-Newsreader: THOR 2.22 (Amiga;TCP/IP)
  11.  
  12.  SM> In article <john.hendrikx.44q1@grafix.xs4all.nl>,
  13.  SM> john.hendrikx@grafix.xs4all.nl (John Hendrikx) writes:
  14. >> In a message of 06 Jan 96 Michael Van Elst wrote to All:
  15. >> 
  16. >>  >> I'd like to see a new set of flags, or somekind of ID stored with
  17. >>  >> each file which tells you the filetype.  In other words taking the
  18. >>  >> 'e' and 's' bit concepts one step further.
  19. [snip]
  20. >> 512 bytes might not be sufficient to make a FileID...
  21.  
  22. I don't know why not. Lemme use an opsys I am *truely* familiar with, #os9#
  23. as the demo here. There, the directories are much more compact at $20 bytes
  24. per entry. Of these, 29. bytes are for the filename string, the final 3 are
  25. the truncated absolute address of the file descriptor sector.  A final $00
  26. is appended to that and a seek to that absolute address on the media puts it
  27. at the first byte of that file descriptor sector.  The first $10 bytes of
  28. that sector define the files attributes (1 byte and a limitation of sorts),
  29. then owners user ID (2 bytes), last modified dates (5 bytes), link count 
  30. (1byte), size (4 bytes) and the date of creation (3 bytes).  The remaining
  31. 240 bytes are assigned in groups of 5, the first 3 for the truncated
  32. absolute sector location on the media, and the next 2 for how many
  33. contiguous sectors starting at that address belong to this file.
  34.  
  35. With 48 "segments" of $FFFF sectors capable of being maped to a single
  36. file, there really isn't a file size limitation other than the 4 byte size.
  37. If I were redoing that opsys today, I would only change one thing based on
  38. personal prefs.  I'd reduce the user number to a byte sized value, and use
  39. the other byte for additional file attribute flags.  8 is not enough IMHO.
  40.  
  41.  SM> Why not store this infomation in the file's .info file?
  42.  
  43.  SM> This kind of auto-recognition of files isn't a feature you would
  44.  SM> expect a command line shell to have --- it's a bit too high 
  45.  SM> level for that IMHO.
  46.  
  47. Imateriel, (sp?)
  48. Since it should be part of the opsys itself, its duty is to tell the shell
  49. via any error messages whether the shell can do that to the file or not.
  50.  
  51.  SM> But the GUI is intended as a 'high-level' interface which goes out
  52.  SM> of it's way to be friendly and helpful (supposedly!).  So storing
  53.  SM> a field in the .info with the file type would be ideal.  The Workbench
  54.  SM> *has* to load the .info files anyway --- so the speed descrease would
  55.  SM> be practically non-existant!
  56.  
  57. But it leaves you dependant on another, seperate file whose only connection
  58. is its name + the ".info".  With rename being handy to all, this *Is A Very
  59. Bad Idea IMHO*
  60.  
  61. Just my $.02 worth
  62.  
  63. [snip]
  64. Hi Fred :)
  65.  SM> -FISH-   ><>
  66.  
  67. Cheers Fred, Gene
  68.  
  69. /*            Gene Heskett          |  These opinions are NOT to be  */
  70. /*  CE @ WDTV Weston/Clarksburg WV  |  confused with the official    */
  71. /*  <gene_heskett@wvlink.mpl.com>   |  WDTV managment views          */
  72. #include <std.disclaimer>
  73.  
  74.  
  75.