home *** CD-ROM | disk | FTP | other *** search
/ OS/2 Professional / OS2PRO194.ISO / os2 / info / faq / os2_20 / os2help / eadata.fax < prev    next >
Encoding:
Text File  |  1992-09-17  |  10.4 KB  |  193 lines
  1. EXTENDED ATTRIBUTES
  2. -------------------
  3.  
  4. Here is a description of the extended attribute mechanism for FAT
  5. partitions.  This document appears to have made the rounds of UseNet,
  6. Compuserve, BIX, etc.  It appears to be reasonably well researched,
  7. but I cannot speak for its correctness.  Hope it proves useful and/or
  8. educational.
  9.  
  10. ==============================================================================
  11.  
  12. The EA DATA. SF file, and what it does
  13. ======================================
  14.  
  15. I originally wrote this because of all the queries about the file named
  16. EA DATA. SF file which is a frequent subject of discussion.  I have
  17. tried to explain what it does, why it exists, and what you should and
  18. should not do with it.  Various people on CompuServe have given me extra
  19. information; particular thanks to Dean Gibson (73427,2072) who figured
  20. out the format of the EA DATA.  SF file and put me right on a few
  21. points.  Some of the following information (and nearly all of Appendix
  22. -Pause- ╒C■ontinue, ╒N■onStop, ╒S■top? ╒C■NA) is due to Dean.
  23.  
  24. OS/2 1.2 and beyond support the concept of "extended attributes" (EAs)
  25. on files.  These are used for all kinds of things, and can be very small
  26. or quite large (the limit is 64K per file at present).  EAs might
  27. represent a file type, a file classification, an icon type, some free
  28. text...practically anything.  Use the Properties entry in the File
  29. pulldown on the File Manager to see the EAs on a specified file
  30. (actually, I have found that Properties doesn't seem to tell you
  31. absolutely everything).
  32.  
  33. EAs are supported directly by the High Performance File System (HPFS).
  34. They are stored in an efficient manner; a small EA does not effectively
  35. take any additional space most of the time (typically, if it is less
  36. than several hundred bytes).
  37.  
  38. However, for backwards compatibility the DOS (File Allocation Table, or
  39. FAT) file system needs to support EAs too.  In order to do this, and
  40. keep the file system consistent for DOS if it is booted instead of OS/2
  41. on the same machine, some trickery is needed.
  42.  
  43. FAT directory entries have ten spare bytes in them, starting at offset
  44. 0CH (immediately after the filename and the attribute byte); these are
  45. normally zero.  They are there because originally the directory entry
  46. layout was modelled on the CP/M file system, and these bytes (among
  47. others) were used to describe the location of the disk extents making up
  48. the file; they aren't used for that purpose under DOS.  Two of these
  49. spare bytes (at offsets 14H and 15H within the directory entry) are used
  50. to head a chain of disk allocation units (or clusters) which hold the
  51. EAs for that file.  This causes interesting problems (for example) with
  52. early versions of the Norton Utilities, which flag the directory entry
  53. as one with an "illegal" format!  So, effectively an OS/2 FAT directory
  54. entry can head two chains of clusters; one for the file itself (as
  55. usual) and one for the EAs attached to the file.  The latter listhead is
  56. often null.
  57.  
  58. All this would be fine until you ran CHKDSK under DOS.  It would find
  59. all these clusters holding the EAs, and because they would appear not to
  60. belong to any file, they would be collected up and marked as "lost"
  61. clusters to be added to the free list.  Disaster next time OS/2 looked
  62. at the file (well, eventually anyway) because the chances are that the
  63. clusters making up the EAs would have been allocated to another file by
  64. that time.  To prevent this, the file named EA DATA. SF (the EA
  65. datafile) is used.  This file is never meant to be read directly.  Its
  66. directory entry heads a chain of clusters (as usual), but these clusters
  67. are the SAME ones that hold all the EAs on that disk.  In other words,
  68. there are two references to every EA cluster; one via the file's
  69. directory entry and one via the EA datafile.  This makes the disk appear
  70. consistent under DOS; all of the clusters used on the disk belong to a
  71. valid file.  Microsoft say that the EA datafile is position dependent,
  72. and it shouldn't be manipulated or deleted; to make this hard, it has a
  73. strange name with spaces in it (which defeats a lot of software), and it
  74. is marked readonly, system and hidden.  Observation has shown this not
  75. to be strictly true; it seems that you can back up and restore the file
  76. without any damage (of course, the EA datafile must correspond to the
  77. files on the disk; if you attempted to restore such a file on its own
  78. without also restoring the various files that reference it, you would
  79. have problems).  The snag is that restored files won't generally have
  80. the entire directory entry restored, so the head of the EA cluster chain
  81. (in offsets 14H and 15H) will be lost (set to zero).
  82.  
  83. Notice the implication for backup under OS/2.  A proper, EA-aware backup
  84. program need not back up the EA datafile; it simply reads the EAs for
  85. each file as it is backed up, and of course it restores them the same
  86. way - with system calls.  So, the fact that OS/2 locks the EA datafile
  87. open is actually a benefit of sorts - it saves the file being backed up
  88. when its contents will never be needed; and it would be semi-useless
  89. unless the directory entries were also restored in their entirety.
  90.  
  91. Why is this file so big?  I can speak only for IBM OS/2 1.2 and 1.3,
  92. which are the ones I have run.  When installing OS/2, the installation
  93. utility scans the OS/2 hard disk (if FAT) for any files it considers
  94. should have EAs on them.  This means all .EXE files for a start.  To
  95. each one it helpfully adds a short EA that marks the file as executable;
  96. this EA is 23 bytes long, but since each EA needs to be in a cluster
  97. unique to the file to which it is attached, it actually occupies a whole
  98. 2K cluster.  Note that EAs are attached at this time even to DOS .EXE
  99. files found on the disk.  In my case this used up 700K of disk space;
  100. your mileage may vary.  Incidentally, the EA datafile is created when
  101. the first EA is attached to any file on the disk; try it out with a
  102. floppy; it also takes one cluster (the first one) for some kind of
  103. internal housekeeping information.  I suspected that this cluster is
  104. some kind of map similar to the FAT, chaining together the clusters
  105. relating to one file within the EA datafile; if so, it would probably
  106. expand if you had a lot of EAs on your disk.  Dean Gibson figured out a
  107. lot more about the format of the file; the details are given in Appendix
  108. A.
  109.  
  110. You can safely delete the EAs from all your DOS files, and from many
  111. OS/2 ones.  Beware, though!  Some files have large EAs that are used for
  112. special purposes.  Ones I know of include some printer drivers, and the
  113. VIEW utility used for the online command reference.  DIR/N will show you
  114. the sizes of the EAs for each file.  To delete the EAs from all of the
  115. files in my DOS directory, I used:
  116.  
  117.     FOR %X IN (*.EXE) DO EAUTIL /S %X
  118.  
  119. This splits off the EA for each file into another file of the same name,
  120. in a subdirectory called EAS (which is created automatically).  Delete
  121. this directory and its contents to free up the space.  The clusters are
  122. automatically removed from the EA datafile at this time.  I have found
  123. this the easiest way to remove EAs.
  124.  
  125. EAs are also removed from the EA datafile if the file to which they are
  126. attached is deleted; this ONLY applies if deletion takes place under
  127. OS/2 (the DOS box will do).  If deleted under vanilla DOS, the EA
  128. datafile retains the "lost" EA clusters; they can be reclaimed by
  129. running CHKDSK under OS/2 (using the installation disk if DLLs or a
  130. swapfile are open on the disk in question).
  131.  
  132. All this of course plays havoc with defragmenters.  They have to work
  133. round all of the scattered, immobile clusters making up the EA datafile.
  134. Yes, it's a kludge; but quite a good one, given the constraint that it
  135. has to look OK under normal DOS as well as provide the functionality
  136. under OS/2.
  137.  
  138. Please let me know if you have any comments on the above; if I receive
  139. more information, I'll produce a further updated version.
  140.  
  141.  
  142. Appendix A - Notes on the format of the EA datafile
  143. ---------------------------------------------------
  144.  
  145. Most of this information came from Dean Gibson - many thanks, Dean!  I
  146. have made the occasional addition.
  147.  
  148. The actual EA DATA.  SF file format is as follows (this has been
  149. verified with both 128 & 512 byte sector disks):
  150.  
  151. The first word is for identification and contains the ASCII characters
  152. 'ED'; the next 15 words seem unused.  The next 240 words (call this
  153. "table A") contain offsets into "table B".  Table B starts at file byte
  154. offset 512 and continues for as many contiguous 128 word segments as
  155. necessary.
  156.  
  157. Given a non-zero 16 bit EA pointer "X" in a FAT system directory entry
  158. (in offsets 14H and 15H):
  159.  
  160.  1. Shift X right 7 bits, and use the result as a WORD INDEX to obtain a
  161.     word entry from table A.  Note that since a FAT system can only have
  162.     64K entries, that means a maximum of 32K files that have EA entries
  163.     (since each file and each EA takes one cluster each), so the max EA
  164.     pointer value is <32K, and thus the high-order bit of X is unused.
  165.  
  166.  2. Use X as a relative WORD INDEX into table B, to obtain the word entry
  167.     at that location.  A value of FFFFH means that the entry is unused.
  168.  
  169.  3. Add the values from steps 2 & 3 to obtain the relative CLUSTER of the EA
  170.     for the target file within EA_DATA._SF.
  171.  
  172. In order to keep the EA DATA. SF file logically contiguous when table B
  173. is expanded into a new cluster or when an EA is deleted, the FAT cluster
  174. chain for EA DATA.  SF is altered, and values in table A and/or segments
  175. of table B are changed to reflect this.
  176.  
  177. The first word of the EA sector is for identification and contains the
  178. ASCII characters 'EA'; the next word is the relative sector number of
  179. this sector (consistency check); then the next two words are zero; the
  180. next twelve bytes contain the target file name (no path); the next word
  181. has an as yet undeciphered meaning; then the next two words are zero;
  182. followed by the EA data for the target file.  The first word of the EA
  183. data is the length of the EA data in bytes, including the count word.
  184.  
  185.  
  186. -------------------------------------------------------------------------------
  187. Thank you for calling the OS/2 2.0 Support Line.  Regarding the problem
  188. reported to the Support Line, we feel that this information may assist
  189. you in resoloving your problem.  If you still require assistance, please
  190. call 1-800-237-5511, and reference your customer number and problem (PMR)
  191. number.  Your Problem Record Number (PMR) should appear on the cover
  192. page of this faxed document.
  193.