home *** CD-ROM | disk | FTP | other *** search
- Newsgroups: comp.os.os2.misc
- Path: sparky!uunet!cs.utexas.edu!qt.cs.utexas.edu!yale.edu!ira.uka.de!chx400!josef!ifi.unizh.ch!erzberg
- From: erzberg@ifi.unizh.ch (Martin Erzberger)
- Subject: Re: Lost Extended Attributes.
- Message-ID: <1992Jul21.061323.21627@ifi.unizh.ch>
- Sender: news@ifi.unizh.ch (USENET News Admin)
- Nntp-Posting-Host: gardhu
- Organization: University of Zurich, Department of Computer Science
- References: <199207201508.AA11238@tuna.wang.com> <1992Jul20.204331.1878@midway.uchicago.edu>
- Date: Tue, 21 Jul 1992 06:13:23 GMT
- Lines: 19
-
- > It fragments
- > because of constant access and updating. You need not defragment it,
- > however, because it is seldom accessed sequentially. HPFS keeps
- > extended attributes in blocks with the file itself and, hence, does
- > not require this file.
- Nah, it fragments because the EA's are stored near the file to which they belong. They are
- linked via directory entries of the files (using some of the reserved attribute bits or so).
- The "file" EA DATA. SF is merely a directory entry (together with the FAT entries) to keep
- the places where the EA's are stored reserved, for all systems which know nothing about EA's
- (means, they cannot interpret the linking bits). This way the EA's will not be overwritten,
- because eg. DOS thinks, there is a "file". OS2/ never uses EA DATA. SF to access the
- extended attributes, as said, it uses the linking bits.
- Now if you defragment EA DATA. SF, the pointers in the directory don't point to the right
- place anymore. CHKDSK get's hold of this, because it compares the place EA DATA. SF claims
- with the places the pointers point to. A OS/2 FAT defragmenter would place the EA's probably
- at the beginning of the corresponding file, and update the pointers AND EA DATA. SF, so
- the link will not be lost. Of course, this will leave EA DATA. SF fragmented, for
- performance reasons.
- Regards, Martin
-