[hfs-user] Re: Hidden files
Sun, 28 Apr 2002 21:44:10 -0700
On Sunday, April 28, 2002, at 08:31 AM, Alex Vallens wrote:
> Entwicklung wrote:
>> How does one get to see hidden files/ change the attributes on Mac OS
>> 9 ?
>> Someone had written that this is possible using Apple's ResEdit but I
>> that was just for editing icons and the like. Can one get to see hidden
>> system-files at all ?
> Yes, absolutely.
>> What else is ResEdit used for normally - is this relevant to external
>> HFS-readonly volumes ?
> ResEdit was created by Apple to allow Mac developers to customize the
> resource forks
> of the apps they created. Since the creation of the Mac in 1984, the
> Mac OS (up to
> X) has used the resource fork to specify things such as file and
> creator types,
> visibility, read/write permissions (lock mechanism), icons, creation and
> modification dates, etc. Every file has one, at least to a certain
Actually that's not exactly correct. The MacOS filesystem, HFS and
HFS+, store some meta-data in the catalog record itself, apart from any
file data in the data fork or resource fork. In addition to some of the
more traditional metadata such as create/modify/backup dates there's 32
bytes of so-called Finder Info, split into two 16-byte records for
historical reasons, that hold fields like the file and creator type, and
flags such as the invisible flag.
"Hidden" (or "invisible") files are just the result of a convention in
the Finder: if the Finder flags have a bit set that indicates the file
should be invisible, the Finder just won't show it. It's still very
much present in the catalog and can be manipulated using all the usual
ResEdit was, as the name suggests, written to edit the contents of the
resource fork of a file, where items like icons, dialogs, and text
strings were stored. In addition some of the Finder flags relate to the
use of the contents of the resource fork: there's a "Bundle bit", for
instance, which hints to the Finder that this file's resource fork
contains a "BNDL" resource that defines new associations between finder
type/creator pairs and icons in this resource fork. For the convenience
of the developer, ResEdit grew to provide access to all of the defined
Finder flags and some other fields as well, so ResEdit can be used to
set or clear the "invisible" bit in the Finder flags.
Although there's a copy of some of the Finder information stored in the
header portion of the resource fork for disk recovery purposes, that is
not the primary storage for that information and that's not where the
filesystem looks for it. Furthermore, files can have a data fork, a
resource fork, both, or neither; not all files have a resource fork
(i.e. it can be of zero length).
Hope that helps,