This is a multi-part message in MIME format.
------=_NextPart_000_0015_01C1D744.98D61740
Content-Type: text/plain;
charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
HI, Everybody
Wishing u all a very Happy Holi.( An Indian festival played
with colours)
Well in the MDB structure for an HFS volume the
field
vol.drXTClpSiz /* clump size for extents overflow file */
is 4 bytes long.
Again in the Catalog Data Record structure the member
filClpSize; /* file clump size */
takes 2 bytes.
=20
Therefore when i assign the value of the first variable to
the second I lose information.
But then one way is to make the MDB's variable contain
a value only for 2 bytes then assignment won't make=20
a data loss. But the value for the MDB's variable was
calculated as 1/128 th part of the Total volume size.
An emphirical formula used in the hfsutils package.
Any comments on this???
Please is there any simple formula to find out the
extent file size and the catalog file size for a volume
when we know before hand how many files have to be
in that volume.
For eg. if i know i have to write "X" files contained in
"Y" number of directories.
Then can i calculate what should be the volume's=20
clump size for the extents overflow file and the catalog=20
file.
Waiting for ur explanations.
=20
Bye
Biswaroop
Each Day gives us an Opprutunity to
Ruin it, those who Fail, Succeed in Life.
-- Bisban
------=_NextPart_000_0015_01C1D744.98D61740
Content-Type: text/html;
charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
HI, Everybody
Wishing u all a very Happy Holi.( =
An Indian=20
festival played
with colours)
Well in the MDB structure for an =
HFS volume=20
the
field
vol.drXTClpSiz /* clump size for =
extents=20
overflow file */
is 4 bytes long.
Again in the Catalog Data Record =
structure=20
the member
filClpSize; /* file clump =
size=20
*/
takes 2 bytes.
Therefore when i assign the =
value of the=20
first variable to
the second I lose =
information.
But then one way is to make the =
MDB's=20
variable contain
a value only for 2 bytes then =
assignment=20
won't make
a data loss. But the value for =
the MDB's=20
variable was
calculated as 1/128 th part of =
the Total=20
volume size.
An emphirical formula used in =
the hfsutils=20
package.
Any comments on =
this???
Please is there any simple =
formula to find=20
out the
extent file size and the catalog =
file size=20
for a volume
when we know before hand how =
many files have=20
to be
in that volume.
For eg. if i know i have to =
write "X"=20
files contained in
"Y" number of =
directories.
Then can i calculate what =
should be=20
the volume's
clump size for the extents =
overflow=20
file and the catalog
file.
Waiting for ur =
explanations.
Bye
Biswaroop
Each Day gives us an Opprutunity =
to
Ruin it,=20
those who Fail, Succeed in=20
Life.
&nbs=
p; =
; =
=
-- Bisban
------=_NextPart_000_0015_01C1D744.98D61740--
From sibaz@sibaz.com Fri Mar 29 14:41:39 2002
From: sibaz@sibaz.com (Simon Bazley)
Date: Fri, 29 Mar 2002 14:41:39 +0000
Subject: [hfs-user] Difference in Data types??
References: <001801c1d716$80320a60$1c0a0a0a@bisban>
Message-ID: <3CA47D23.948787B6@sibaz.com>
Firstly, check out the code for the hfs file system on linux. Theres a
lot of helpful little tricks when implementing things in C. In
particular there is a directive which when added to the end of a struct
made it pack as you'd expect it to instead of doing strange things
similar to what you're suggesting.
Again working out assumtions is easy when you can see how someone else
has done it.
As for working out catalog file sizes based on the number of files, you
can't. The problem is the eventual catalog size will be based on the
number of nodes in the file, and the number of nodes depends on howmany
files you can get in each node. That depends on the record size within
the node and that varies for some node types, depending on the length of
the filename. There are 4 types of node in a catalog file, I believe
only 2 will vary in this way. It may be all 4, I'm not sure. Extent
files however don't vary like this so you can work it out. Just
checkout how big key structure is in an extents file, then work out the
packing density of that structure in a node. Remember though that Nodes
are 512 bytes (I think) in HFS, but 4k in HFS+ (this is because the
maximum name length changed in HFS+, so records could be up to 4k big).
I suspect you're best just to create all the keys then just combine them
together and see what you get. I'm sure you could work it out, but It'd
be easier just to make a massive file, then shrink it to the used size
when you've finished adding stuff.
The size of the Catalog file and extents file (allocated size and nodes
used) are stored in the mdb, incase that was what you meant.
Simon
"Biswaroop(External)" wrote:
> HI, Everybody Wishing u all a very Happy Holi.( An Indian festival
> played with colours) Well in the MDB structure for an HFS volume
> the field vol.drXTClpSiz /* clump size for extents overflow file */
> is 4 bytes long. Again in the Catalog Data Record structure the
> member filClpSize; /* file clump size */ takes 2 bytes. Therefore
> when i assign the value of the first variable to the second I lose
> information. But then one way is to make the MDB's variable contain
> a value only for 2 bytes then assignment won't make a data loss. But
> the value for the MDB's variable was calculated as 1/128 th part of
> the Total volume size. An emphirical formula used in the hfsutils
> package. Any comments on this??? Please is there any simple formula
> to find out the extent file size and the catalog file size for a
> volume when we know before hand how many files have to be in that
> volume. For eg. if i know i have to write "X" files contained in
> "Y" number of directories. Then can i calculate what should be the
> volume's clump size for the extents overflow file and the catalog
> file. Waiting for ur explanations. Bye Biswaroop Each Day gives us
> an Opprutunity to
> Ruin it, those who Fail, Succeed in Life.
> -- Bisban
From mday@apple.com Fri Mar 29 17:07:55 2002
From: mday@apple.com (Mark Day)
Date: Fri, 29 Mar 2002 09:07:55 -0800
Subject: [hfs-user] Difference in Data types??
In-Reply-To: <001801c1d716$80320a60$1c0a0a0a@bisban>
Message-ID: <82FABBB5-4337-11D6-AEAE-00039354009A@apple.com>
On Friday, March 29, 2002, at 03:40 AM, Biswaroop(External) wrote:
> Well in the MDB structure for an HFS volume the
> field
> vol.drXTClpSiz /* clump size for extents overflow file */
> is 4 bytes long.
> Again in the Catalog Data Record structure the member
> filClpSize; /* file clump size */
> takes 2 bytes.
>
> Therefore when i assign the value of the first variable to
> the second I lose information.
I'm not sure why you're copying from one to the other. The drXTClpSiz
is the clump size for the extents B-tree only. Since the B-tree is used
in a very different way from typical user files, I don't see a reason to
try and set an ordinary file's clump size to be the same as one of the
B-trees.
I believe Apple's code sets the clump size in a catalog record to zero;
I think you can do the same. It turns out that having different clump
sizes for different files wasn't very useful. If an application really
wanted to make sure that a file was allocated in large contiguous
pieces, it was generally better to try and pre-allocate it in one giant
contiguous piece (or when allocating additional space, make the entire
allocation contiguous). At runtime, Apple's code just uses a
volume-wide default for ordinary files (i.e. ones with a catalog record).
> Please is there any simple formula to find out the
> extent file size and the catalog file size for a volume
> when we know before hand how many files have to be
> in that volume.
> For eg. if i know i have to write "X" files contained in
> "Y" number of directories.
> Then can i calculate what should be the volume's
> clump size for the extents overflow file and the catalog
> file.
Certainly no simple formula for the catalog B-tree. In part that is
because the size of the catalog is determined in part by the lengths of
the file and directory names (even more so on HFS Plus, where the keys
in index nodes are variable length). And for volumes that are modified
over time, the order of operations will affect the size of the B-tree in
complex ways. I'm sure you could come up with a statistical guess based
on average name lengths, average density of nodes (i.e. how "full" they
are), etc.
Your particular case of creating a CD is actually a much simpler
problem, and you can compute an exact answer if you want. Since the
files won't be modified over time, you can guarantee that they will not
be fragmented. That means you can get by with a minimal extents B-tree
containing no leaf records. That means a single allocation block (for
the header node; the other nodes are unused and should be filled with
zeroes).
Since you know the complete set of files and directories in advance, you
can build an optimal tree by packing as many leaf records in a node as
possible, and then moving to the next node. All it requires is knowing
the order that you will assign directory IDs to directories, and then be
able to sort the file and directory names for the items in a single
directory. That way you can predict the entire leaf sequence. Once you
know the number of leaf nodes, you can calculate the number of index
nodes that will be parents of the leaf nodes, and so on up the tree
until you get to a level containing exactly one node (the root). This
should be relatively easy for HFS because the records in index nodes are
constant size, so the calculation for each level should just be a simple
divide and round up. For HFS Plus, you would have to keep track of the
actual file or directory names since the length of the keys in index
nodes vary based on the name lengths.
If that's too complicated, you could always fall back to assuming a
constant size (maximum or average) for all of the records. Don't forget
that for thread records, the key is of fixed size but the data is
variable (since it contains a variable-length string).
-Mark
From jcpearso@ps.ucl.ac.uk Tue Apr 2 11:57:31 2002
From: jcpearso@ps.ucl.ac.uk (James Pearson)
Date: Tue, 02 Apr 2002 12:57:31 +0100
Subject: [hfs-user] Difference in Data types??
In-Reply-To: Your message of Fri, 29 Mar 2002 09:07:55 -0800.
<82FABBB5-4337-11D6-AEAE-00039354009A@apple.com>
Message-ID: <281412.1017748651@ourhome.freeserve.co.uk>
>Certainly no simple formula for the catalog B-tree. In part that is
>because the size of the catalog is determined in part by the lengths of
>the file and directory names (even more so on HFS Plus, where the keys
>in index nodes are variable length). And for volumes that are modified
>over time, the order of operations will affect the size of the B-tree in
>complex ways. I'm sure you could come up with a statistical guess based
>on average name lengths, average density of nodes (i.e. how "full" they
>are), etc.
> ....
>If that's too complicated, you could always fall back to assuming a
>constant size (maximum or average) for all of the records. Don't forget
>that for thread records, the key is of fixed size but the data is
>variable (since it contains a variable-length string).
That's what I did for the mkhybrid code - I didn't want the catalog "file"
to grow, so by trial and error, I set the initial size of the catalog file
to twice the "default" used by the libhfs routines in hfsutils. This seems
to work OK for virtually all cases (if this is isn't big enough, the mkhybrid
code uses a brute force approach and 're-creates' the HFS side of the file
system with a new default size twice as big again ...).
James Pearson
From entwicklung@whengenibk.de Tue Apr 2 14:33:26 2002
From: entwicklung@whengenibk.de (Entwicklung)
Date: Tue, 2 Apr 2002 16:33:26 +0200
Subject: [hfs-user] Differences - HFS/HFS+
Message-ID: <000a01c1da53$5a2bdf90$0400a7c0@modemserver>
This is a multi-part message in MIME format.
------=_NextPart_000_0007_01C1DA64.1D2E4180
Content-Type: text/plain;
charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Hello listers,
I'm trying to extend an HFS-volume to an HFS+ volume. =
Going by the specifications I've gathered the major differences which =
would play a role in the construction of an image.....
1) Difference in Allocation Block Size
2) Difference in basic structure of B-Tree components , MDB Vs. Volume =
Header etc. (incl. respective fields, kind of fields etc.)
3) Difference in NodeSize of the catalog
4) Thread records must be maintained even for files in HFS+
Anything else I've left out / overlooked ?=20
All I want to achieve is to modify my algos for HFS to work for HFS+ as =
well . I guess the variation in the allocation block size would help =
optimize disk space for HFS+.
Any other major / minor aspect I should be considering ?=20
Regards,
Nandini=20
------=_NextPart_000_0007_01C1DA64.1D2E4180
Content-Type: text/html;
charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Hello listers,
&nbs=
p; =20
I'm trying to extend an HFS-volume to an HFS+ volume. Going by the=20
specifications I've gathered the major differences which would play a =
role in=20
the construction of an image.....
1) Difference in Allocation Block =
Size
2) Difference in basic structure of =
B-Tree=20
components , MDB Vs. Volume Header etc. (incl. respective fields, kind =
of fields=20
etc.)
3) Difference in NodeSize of the=20
catalog
4) Thread records must be maintained =
even for files=20
in HFS+
Anything else I've left out / =
overlooked ?=20
All I want to achieve is to modify my =
algos for HFS=20
to work for HFS+ as well . I guess the variation in the allocation block =
size=20
would help optimize disk space for HFS+.
Any other major / minor aspect I should =
be=20
considering ?
Regards,
Nandini
------=_NextPart_000_0007_01C1DA64.1D2E4180--
From mday@apple.com Tue Apr 2 18:51:59 2002
From: mday@apple.com (Mark Day)
Date: Tue, 2 Apr 2002 10:51:59 -0800
Subject: [hfs-user] Differences - HFS/HFS+
In-Reply-To: <000a01c1da53$5a2bdf90$0400a7c0@modemserver>
Message-ID:
On Tuesday, April 2, 2002, at 06:33 AM, Entwicklung wrote:
> I'm trying to extend an HFS-volume to an HFS+ volume.
> Going by the specifications I've gathered the major differences which
> would play a role in the construction of an image.....
>
> 1) Difference in Allocation Block Size
> 2) Difference in basic structure of B-Tree components , MDB Vs. Volume
> Header etc. (incl. respective fields, kind of fields etc.)
> 3) Difference in NodeSize of the catalog
> 4) Thread records must be maintained even for files in HFS+
>
> Anything else I've left out / overlooked ?
The keys in index nodes of an HFS Plus catalog are variable sized (based
on the actual length of the string part of the key). If the keys are
longer than they need to be (i.e. you have bytes in the key beyond the
end of the string), the disk isn't technically corrupt, but it is
wasteful, and some repair utilities will complain.
If you're modifying an existing HFS Plus catalog, this leads to a
behavior that may be surprising. Deleting a file or directory can cause
the catalog B-tree to grow. If you end up deleting the first key in a
leaf node, that key needs to be replaced in its parent (an index node),
and perhaps other ancestors. If the replacement key is longer, there
might not be room in the index nodes, so they may have to split.
For mastering read-only volumes, you may not have to worry about that.
You could just build up the leaf sequence directly, and then each of the
levels of index nodes.
-Mark
From entwicklung@whengenibk.de Thu Apr 4 13:44:00 2002
From: entwicklung@whengenibk.de (Entwicklung)
Date: Thu, 4 Apr 2002 15:44:00 +0200
Subject: [hfs-user] Problems with HFS+ empty volume...
Message-ID: <000a01c1dbde$c750aba0$0400a7c0@modemserver>
This is a multi-part message in MIME format.
------=_NextPart_000_0007_01C1DBEF.8A5D94E0
Content-Type: text/plain;
charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Hello Listers,
I just wanted to check if anyone knows if it is =
essential to have an empty B-Tree for the attribute and startup file in =
an HFS+ image. In case of HFS these weren't present in my image. In case =
of HFS+ I've increased the node size of the catalog to 4kB and included =
the other changes as discussed. Only thing I haven't done is to create a =
B-Tree for the attributes file and the start up file - in short I'm not =
writing anything into the image for these and have set the respective =
extents, sizes setc. to 0 in the Volume Header. Is this right or should =
these be present in the image as 'empty' B-Trees ???
I'm right now creating an empty volume with 0 contents but just the =
basic structures needed (the way I started off for HFS). The only =
problem is that I don't have any utilities to create sample HFS+ images =
which I can cross-check my image with.... Disk Copy on my iMac with =
MacOS 9 creates only HFS-Volumes by default and Norton Disk Doctor on my =
Mac recognizes the volume as MacOS Extended but doesn't really bring me =
any further (since my Mac is unable to mount the volume). There seems to =
be a hfsplus reader on Sourceforge since the end of last year but I need =
something like a sample hfsplus writer. Any idea if sth like this exists =
on the Mac or on other platforms. My Mac has just a CD-drive (no writer) =
and no floppy drive which make file transfer as cumbersome as it can =
get.
Any idea why this fails ? Would be glad for any suggestions/tips...
Regards,
Nandini=20
------=_NextPart_000_0007_01C1DBEF.8A5D94E0
Content-Type: text/html;
charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Hello Listers,
&nbs=
p; =20
I just wanted to check if anyone knows if it is essential to have =
an empty=20
B-Tree for the attribute and startup file in an HFS+ image. In case of =
HFS these=20
weren't present in my image. In case of HFS+ I've increased the node =
size of the=20
catalog to 4kB and included the other changes as discussed. Only thing I =
haven't=20
done is to create a B-Tree for the attributes file and the start up file =
- in=20
short I'm not writing anything into the image for these and have set the =
respective extents, sizes setc. to 0 in the Volume Header. Is this right =
or=20
should these be present in the image as 'empty' B-Trees ???
I'm right now creating an empty volume =
with 0=20
contents but just the basic structures needed (the way I started off for =
HFS). The only problem is that I don't have any utilities to create =
sample HFS+ images which I can cross-check my image with.... Disk =
Copy on=20
my iMac with MacOS 9 creates only HFS-Volumes by default and Norton Disk =
Doctor=20
on my Mac recognizes the volume as MacOS Extended but doesn't =
really bring=20
me any further (since my Mac is unable to mount the volume). There seems =
to be a=20
hfsplus reader on Sourceforge since the end of last year but I need =
something=20
like a sample hfsplus writer. Any idea if sth like this exists on the =
Mac or on=20
other platforms. My Mac has just a CD-drive (no writer) and no floppy =
drive=20
which make file transfer as cumbersome as it can get.
Any idea why this fails ? =
Would be glad for any =
suggestions/tips...
Regards,
Nandini
------=_NextPart_000_0007_01C1DBEF.8A5D94E0--
From entwicklung@whengenibk.de Fri Apr 5 10:02:37 2002
From: entwicklung@whengenibk.de (Entwicklung)
Date: Fri, 5 Apr 2002 12:02:37 +0200
Subject: Fw: [hfs-user] Problems with HFS+ empty volume...
Message-ID: <002001c1dc89$0494b790$0400a7c0@modemserver>
This is a multi-part message in MIME format.
------=_NextPart_000_001D_01C1DC99.C750C1B0
Content-Type: text/plain;
charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Hello Listers,
I would be grateful to anyone who could just take a =
look at the following code ( for the HFS+ Volume Header) and let me know =
if there are any major defects. I'm having a problem detecting the point =
of failure - the volume contains 0 files or directories and is not even =
getting mounted.
Could it be that not setting the attributes file and startupfile to =
anthing is creating some problem ?
I'm probably missing out on something basic here and am not able to =
proceed...please help if you can.
Regards,
Nandini
=20
HFSPlusVolumeHeader myVolumeHeader;=20
myVolHeader.signature=3DkHFSPlusSigWord;
myVolHeader.version=3DkHFSPlusVersion;// current version is =
kHFSPlusVersion=20
myVolHeader.attributes=3D0x0100; // volume attributes=20
myVolHeader.lastMountedVersion=3DkHFSPlusMountVersion; // =
implementation version which last mounted volume=20
myVolHeader.reserved=3D0; // reserved - set to zero=20
myVolHeader.createDate=3DVolCrDate; // date and time of =
volume creation=20
myVolHeader.modifyDate=3DVolCrDate; // date and time of =
last modification=20
myVolHeader.backupDate=3DVolCrDate; // date and time of =
last backup=20
myVolHeader.checkedDate=3DVolCrDate; // date and time of =
last disk check=20
myVolHeader.fileCount=3D0; // number of files in volume=20
myVolHeader.folderCount=3D0; // number of directories in volume=20
myVolHeader.blockSize=3D512; // size (in bytes) of allocation =
blocks=20
myVolHeader.totalBlocks=3D28;/*assuming =20
allocation block=3D 512 bytes; number of allocation blocks in volume =
(includes this header and VBM)*/
myVolHeader.freeBlocks=3D0; // number of unused allocation =
blocks=20
myVolHeader.nextAllocation=3D0; // start of next allocation =
search=20
myVolHeader.rsrcClumpSize=3D512; // default resource fork clump =
size=20
myVolHeader.dataClumpSize=3D512; // default data fork clump =
size=20
myVolHeader.nextCatalogID=3D0x00000000; // next unused catalog =
node ID=20
myVolHeader.writeCount=3D0x00000000; // volume write count=20
myVolHeader.encodingsBitmap[0]=3D0x00000000; // which encodings =
have been used on this volume=20
myVolHeader.encodingsBitmap[1]=3D0x00000000;
=20
for(int i=3D0;i<32;i++)
myVolHeader.finderInfo[i]=3D0x00; // information used by the =
Finder=20
myVolHeader.allocationFile.clumpSize=3D512; // allocation =
bitmap file=20
myVolHeader.allocationFile.extents[0].blockCount=3D1;
myVolHeader.allocationFile.extents[0].startBlock=3D3;
for(i=3D1;i<8;i++)
{=20
myVolHeader.allocationFile.extents[i].blockCount=3D0;
myVolHeader.allocationFile.extents[i].startBlock=3D0;
}
myVolHeader.allocationFile.logicalSize[0]=3D0;
myVolHeader.allocationFile.logicalSize[1]=3D512;
myVolHeader.allocationFile.totalBlocks=3D1;
=20
myVolHeader.extentsFile.clumpSize=3D512; // extents B-tree =
file=20
myVolHeader.extentsFile.extents[0].blockCount=3D4;
myVolHeader.extentsFile.extents[0].startBlock=3D4;=20
for(i=3D1;i<8;i++)
{=20
myVolHeader.extentsFile.extents[i].blockCount=3D0;
myVolHeader.extentsFile.extents[i].startBlock=3D0;
}
myVolHeader.extentsFile.logicalSize[0]=3D0;
myVolHeader.extentsFile.logicalSize[1]=3D512*4;
myVolHeader.extentsFile.totalBlocks=3D4;
=20
myVolHeader.catalogFile.clumpSize=3D512; // catalog B-tree =
file=20
myVolHeader.catalogFile.extents[0].blockCount=3D4*4;
=
myVolHeader.catalogFile.extents[0].startBlock=3DmyVolHeader.extentsFile.e=
xtents[0].startBlock+4;
for(i=3D1;i<8;i++)
{=20
myVolHeader.catalogFile.extents[i].blockCount =3D0;
myVolHeader.catalogFile.extents[i].startBlock=3D0;
}
myVolHeader.catalogFile.logicalSize[0]=3D0;
myVolHeader.catalogFile.logicalSize[1]=3D512*4*4;
myVolHeader.catalogFile.totalBlocks=3D4*4;
=20
myVolHeader.attributesFile.clumpSize=3D512; // extended =
attributes B-tree file=20
for(i=3D0;i<8;i++)
{ =20
myVolHeader.attributesFile.extents[i].blockCount=3D0;
myVolHeader.attributesFile.extents[i].startBlock=3D0;
}
myVolHeader.attributesFile.logicalSize[0]=3D0;
myVolHeader.attributesFile.logicalSize[1]=3D0;
myVolHeader.attributesFile.totalBlocks=3D0;
=20
myVolHeader.startupFile.clumpSize=3D512; // boot file=20
for(i=3D0;i<8;i++)
{=20
myVolHeader.startupFile.extents[i].blockCount=3D0;
myVolHeader.startupFile.extents[i].startBlock=3D0;
}
myVolHeader.startupFile.logicalSize[0]=3D0;
myVolHeader.startupFile.logicalSize[1]=3D0;
myVolHeader.startupFile.totalBlocks=3D0;
=20
----- Original Message -----=20
From: Entwicklung=20
To: hfs-user@lists.mars.org=20
Sent: Thursday, April 04, 2002 3:44 PM
Subject: [hfs-user] Problems with HFS+ empty volume...
Hello Listers,
I just wanted to check if anyone knows if it is =
essential to have an empty B-Tree for the attribute and startup file in =
an HFS+ image. In case of HFS these weren't present in my image. In case =
of HFS+ I've increased the node size of the catalog to 4kB and included =
the other changes as discussed. Only thing I haven't done is to create a =
B-Tree for the attributes file and the start up file - in short I'm not =
writing anything into the image for these and have set the respective =
extents, sizes setc. to 0 in the Volume Header. Is this right or should =
these be present in the image as 'empty' B-Trees ???
=20
I'm right now creating an empty volume with 0 contents but just the =
basic structures needed (the way I started off for HFS). The only =
problem is that I don't have any utilities to create sample HFS+ images =
which I can cross-check my image with.... Disk Copy on my iMac with =
MacOS 9 creates only HFS-Volumes by default and Norton Disk Doctor on my =
Mac recognizes the volume as MacOS Extended but doesn't really bring me =
any further (since my Mac is unable to mount the volume). There seems to =
be a hfsplus reader on Sourceforge since the end of last year but I need =
something like a sample hfsplus writer. Any idea if sth like this exists =
on the Mac or on other platforms. My Mac has just a CD-drive (no writer) =
and no floppy drive which make file transfer as cumbersome as it can =
get.
Any idea why this fails ? Would be glad for any suggestions/tips...
Regards,
Nandini=20
------=_NextPart_000_001D_01C1DC99.C750C1B0
Content-Type: text/html;
charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Hello Listers,
&nbs=
p; =20
I would be grateful to anyone who could just take a look at the =
following code (=20
for the HFS+ Volume Header) and let me know if there are any major =
defects. I'm=20
having a problem detecting the point of failure - the volume contains 0 =
files or=20
directories and is not even getting mounted.
Could it be that not setting the =
attributes file=20
and startupfile to anthing is creating some problem ?
I'm probably missing out on something =
basic here=20
and am not able to proceed...please help if you can.
Regards,
Nandini
HFSPlusVolumeHeader myVolumeHeader; =
=20
myVolHeader.signature=3DkHFSPlusSigWord;
=20
myVolHeader.version=3DkHFSPlusVersion;// current version is =
kHFSPlusVersion=20
=20
myVolHeader.attributes=3D0x0100; =
; =20
// volume attributes
=20
myVolHeader.lastMountedVersion=3DkHFSPlusMountVersion; =
//=20
implementation version which last mounted volume
=20
myVolHeader.reserved=3D0; =
=20
// reserved - set to zero
=20
myVolHeader.createDate=3DVolCrDate; &n=
bsp; =20
// date and time of volume creation
=20
myVolHeader.modifyDate=3DVolCrDate; &n=
bsp; =20
// date and time of last modification
=20
myVolHeader.backupDate=3DVolCrDate; &n=
bsp; =20
// date and time of last backup
=20
myVolHeader.checkedDate=3DVolCrDate; &=
nbsp; =20
// date and time of last disk check
=20
myVolHeader.fileCount=3D0; // =
number of=20
files in volume
=20
myVolHeader.folderCount=3D0; // =
number of=20
directories in volume
=20
myVolHeader.blockSize=3D512; &nb=
sp; =20
// size (in bytes) of allocation blocks
=20
myVolHeader.totalBlocks=3D28;/*assuming
allocation block=3D 512 =
bytes; number of=20
allocation blocks in volume (includes this header and VBM)*/
=20
myVolHeader.freeBlocks=3D0; &nbs=
p; =20
// number of unused allocation blocks
=20
myVolHeader.nextAllocation=3D0; // =
start of=20
next allocation search
=20
myVolHeader.rsrcClumpSize=3D512; =
; //=20
default resource fork clump size
=20
myVolHeader.dataClumpSize=3D512; =
; //=20
default data fork clump size
=20
myVolHeader.nextCatalogID=3D0x00000000; &nbs=
p; =20
// next unused catalog node ID
=20
myVolHeader.writeCount=3D0x00000000; &=
nbsp; =20
// volume write count
=20
myVolHeader.encodingsBitmap[0]=3D0x00000000; =
; =20
// which encodings have been used on this volume
=20
myVolHeader.encodingsBitmap[1]=3D0x00000000;
=
for(int=20
i=3D0;i<32;i++)
myVolHeader.finderInfo[i]=3D0x00; =
=20
// information used by the Finder
=20
myVolHeader.allocationFile.clumpSize=3D512; =
=20
// allocation bitmap file
=20
myVolHeader.allocationFile.extents[0].blockCount=3D1;
=20
myVolHeader.allocationFile.extents[0].startBlock=3D3;
=20
for(i=3D1;i<8;i++)
{
=20
myVolHeader.allocationFile.extents[i].blockCount=3D0;
&nbs=
p;=20
myVolHeader.allocationFile.extents[i].startBlock=3D0;
=
}
=20
myVolHeader.allocationFile.logicalSize[0]=3D0;
=20
myVolHeader.allocationFile.logicalSize[1]=3D512;
=20
myVolHeader.allocationFile.totalBlocks=3D1;
=20
myVolHeader.extentsFile.clumpSize=3D512; &nb=
sp; =20
// extents B-tree file
=20
myVolHeader.extentsFile.extents[0].blockCount=3D4;
=20
myVolHeader.extentsFile.extents[0].startBlock=3D4;
=20
for(i=3D1;i<8;i++)
{
=20
myVolHeader.extentsFile.extents[i].blockCount=3D0;
=20
myVolHeader.extentsFile.extents[i].startBlock=3D0;
}
=
myVolHeader.extentsFile.logicalSize[0]=3D0;
=20
myVolHeader.extentsFile.logicalSize[1]=3D512*4;
=20
myVolHeader.extentsFile.totalBlocks=3D4;
=20
myVolHeader.catalogFile.clumpSize=3D512; &nb=
sp; =20
// catalog B-tree file
=20
myVolHeader.catalogFile.extents[0].blockCount=3D4*4;
=20
myVolHeader.catalogFile.extents[0].startBlock=3DmyVolHeader.extentsFile.e=
xtents[0].startBlock+4;
=20
for(i=3D1;i<8;i++)
{=20
myVolHeader.catalogFile.extents[i].blockCount=20
=3D0;
myVolHeader.catalogFile.extents[i].startBlock=3D0;
&nbs=
p;=20
}
myVolHeader.catalogFile.logicalSize[0]=3D0;
=20
myVolHeader.catalogFile.logicalSize[1]=3D512*4*4;
=20
myVolHeader.catalogFile.totalBlocks=3D4*4;
=20
myVolHeader.attributesFile.clumpSize=3D512; =
=20
// extended attributes B-tree file
=
for(i=3D0;i<8;i++)
=20
{ =20
myVolHeader.attributesFile.extents[i].blockCount=3D0;
=
myVolHeader.attributesFile.extents[i].startBlock=3D0;
=20
}
myVolHeader.attributesFile.logicalSize[0]=3D0;
=20
myVolHeader.attributesFile.logicalSize[1]=3D0;
=20
myVolHeader.attributesFile.totalBlocks=3D0;
=20
myVolHeader.startupFile.clumpSize=3D512; &nb=
sp; =20
// boot file
for(i=3D0;i<8;i++)
{=20
myVolHeader.startupFile.extents[i].blockCount=3D0;
myV=
olHeader.startupFile.extents[i].startBlock=3D0;
=20
}
myVolHeader.startupFile.logicalSize[0]=3D0;
=20
myVolHeader.startupFile.logicalSize[1]=3D0;
=20
myVolHeader.startupFile.totalBlocks=3D0;
=
----- Original Message -----
From:=20
Entwicklung
To: hfs-user@lists.mars.org
Sent: Thursday, April 04, 2002 =
3:44=20
PM
Subject: [hfs-user] Problems =
with HFS+=20
empty volume...
Hello Listers,
&nbs=
p; =20
I just wanted to check if anyone knows if it is essential to have =
an=20
empty B-Tree for the attribute and startup file in an HFS+ image. In =
case of=20
HFS these weren't present in my image. In case of HFS+ I've increased =
the node=20
size of the catalog to 4kB and included the other changes as =
discussed. Only=20
thing I haven't done is to create a B-Tree for the attributes file and =
the=20
start up file - in short I'm not writing anything into the image for =
these and=20
have set the respective extents, sizes setc. to 0 in the Volume =
Header. Is=20
this right or should these be present in the image as 'empty' B-Trees=20
???
I'm right now creating an empty =
volume with 0=20
contents but just the basic structures needed (the way I started off =
for=20
HFS). The only problem is that I don't have any utilities to =
create=20
sample HFS+ images which I can cross-check my image with.... Disk =
Copy on=20
my iMac with MacOS 9 creates only HFS-Volumes by default and Norton =
Disk=20
Doctor on my Mac recognizes the volume as MacOS Extended =
but doesn't=20
really bring me any further (since my Mac is unable to mount the =
volume).=20
There seems to be a hfsplus reader on Sourceforge since the end of =
last year=20
but I need something like a sample hfsplus writer. Any idea if sth =
like this=20
exists on the Mac or on other platforms. My Mac has just a CD-drive =
(no=20
writer) and no floppy drive which make file transfer as cumbersome as =
it can=20
get.
Any idea why this fails ? =
Would be glad for any =
suggestions/tips...
Regards,
Nandini
------=_NextPart_000_001D_01C1DC99.C750C1B0--
From mday@apple.com Fri Apr 5 16:59:35 2002
From: mday@apple.com (Mark Day)
Date: Fri, 5 Apr 2002 08:59:35 -0800
Subject: [hfs-user] Problems with HFS+ empty volume...
In-Reply-To: <000a01c1dbde$c750aba0$0400a7c0@modemserver>
Message-ID: <81D6E2A7-48B6-11D6-BCBC-00039354009A@apple.com>
On Thursday, April 4, 2002, at 05:44 AM, Entwicklung wrote:
> I just wanted to check if anyone knows if it is
> essential to have an empty B-Tree for the attribute and startup file in
> an HFS+ image. In case of HFS these weren't present in my image. In
> case of HFS+ I've increased the node size of the catalog to 4kB and
> included the other changes as discussed. Only thing I haven't done is
> to create a B-Tree for the attributes file and the start up file - in
> short I'm not writing anything into the image for these and have set
> the respective extents, sizes setc. to 0 in the Volume Header. Is this
> right or should these be present in the image as 'empty' B-Trees ???
Just leave them with zero length and zeroes for the extents.
The Attributes B-tree has never been used, nor even fully designed; it
was left as a placeholder so we could extend the volume format in the
future.
The Startup file would typically be used for extra code or data needed
early in booting (perhaps before you've loaded enough code to search the
catalog or extents B-trees). It typically wouldn't be a B-tree at all.
> The only problem is that I don't have any utilities to create
> sample HFS+ images which I can cross-check my image with.... Disk Copy
> on my iMac with MacOS 9 creates only HFS-Volumes by default
In Mac OS 9, use Disk Copy to create a read/write disk image that is at
least 32MB. That is the minimum size volume that Mac OS 9 will format
as HFS Plus (though it should recognize smaller volumes).
-Mark
From entwicklung@whengenibk.de Sat Apr 6 12:50:05 2002
From: entwicklung@whengenibk.de (Entwicklung)
Date: Sat, 6 Apr 2002 14:50:05 +0200
Subject: Fw: [hfs-user] Problems with HFS+ empty volume...
References:
Message-ID: <001201c1dd69$940ed870$0400a7c0@modemserver>
Hello Mark,
> myVolHeader.lastMountedVersion=kHFSPlusMountVersion; //
> implementation version which last mounted volume
You should pick some other constant unique to your implementation. That
way, if a bug is found in your implementation, other implementations can
check this version to correct for the bug.
In my case I've reset kHFSPlusMountVersion to my own unique creator-code
registered with Apple (it doesn't hold '8.10' in my case)
> myVolHeader.folderCount=0; // number of directories in volume
That may be wrong. I can't remember whether the folder count includes
the root directory.
The HFS+ TN says that it doesn't include the root folder.
> myVolHeader.nextCatalogID=0x00000000; // next unused catalog
> node ID
That number should be at least 16 (the minimum ID for ordinary files and
folders).
In case of HFS I just played around with these values and set this field to
0. This didn't affect readability in any way and my volume is a read-only
medium so no further CNID's will be assigned. This was why I've set it to 0
for HFS+ too... maybe some extra check is being made in case of HFS+ so I'll
change this to 16.
> myVolHeader.encodingsBitmap[0]=0x00000000; // which encodings
> have been used on this volume
> myVolHeader.encodingsBitmap[1]=0x00000000;
You should probably set at least bit 0 of the first field. That
corresponds to the MacRoman encoding, which is the fallback when other
encodings don't work.
OK.. I'll do that
In general, if you're mastering CDs, the physical sector size will be
2048 bytes per sector. You might as well make the allocation block size
and clump sizes 2048 as well. That way, one sector is one block, and
the math is a little easier. On Mac OS X, performance may be slightly
better if the allocation block size is 4096 (the same as its VM page
size); of course you'd only do this if you can fit all of your data in
4KB allocation blocks.
It's true that the math is a little easier but making the allocation block
bigger would not
particulary help in space-saving, would it ? In case of a CD of 650MB there
isn't much of space-saving in case of HFS+ anyway but after reading the
Specs and browsing a number of websites I came to the conclusion that my
allocation block size should be 'as small as possible and as large as
necessary'. Do correct me if I'm wrong..... In case of HFS I don't have have
a choice but for HFS+ it shouldn't be a problem setting the block-size to
512 even for images greater in size than 32MB, should it ?
I thought that was the major improvement of HFS+ over HFS.
> The only problem is that I don't have any utilities to create
> sample HFS+ images which I can cross-check my image with.... Disk Copy
> on my iMac with MacOS 9 creates only HFS-Volumes by default
In Mac OS 9, use Disk Copy to create a read/write disk image that is at
least 32MB. That is the minimum size volume that Mac OS 9 will format
as HFS Plus (though it should recognize smaller volumes).
I just tried this out ... It works fine for volumes >32MB. Thanks !
Btw. yesterday I also came across a software MacOpener 2000 which creates
HFS+ images. After a large no. of searches this was practically the only
cross-platform tool I came across which can supposedly read and write HFS+
volumes (not freeware however). I would have probably considered buying it
if I hadn't got this bit of info from you.... but maybe someone else on the
list can make use of it after all...
Regards,
Nandini
From mday@apple.com Mon Apr 8 17:33:46 2002
From: mday@apple.com (Mark Day)
Date: Mon, 8 Apr 2002 09:33:46 -0700
Subject: Fw: [hfs-user] Problems with HFS+ empty volume...
In-Reply-To: <001201c1dd69$940ed870$0400a7c0@modemserver>
Message-ID: <65E99238-4B0E-11D6-A93A-00039354009A@apple.com>
I Wrote:
> In general, if you're mastering CDs, the physical sector size will be
> 2048 bytes per sector. You might as well make the allocation block size
> and clump sizes 2048 as well. That way, one sector is one block, and
> the math is a little easier. On Mac OS X, performance may be slightly
> better if the allocation block size is 4096 (the same as its VM page
> size); of course you'd only do this if you can fit all of your data in
> 4KB allocation blocks.
On Saturday, April 6, 2002, at 04:50 AM, Entwicklung wrote:
> It's true that the math is a little easier but making the allocation
> block
> bigger would not
> particulary help in space-saving, would it ? In case of a CD of 650MB
> there
> isn't much of space-saving in case of HFS+ anyway but after reading the
> Specs and browsing a number of websites I came to the conclusion that my
> allocation block size should be 'as small as possible and as large as
> necessary'.
If there is any overall savings, it would only be a few hundred
kilobytes (due to a smaller volume bitmap). It might actually take more
space if you had lots of small files (due to rounding up to whole
allocation blocks).
The point was more that if you're already aligning the data to 2KB
boundaries (for performance, or because you're making a hybrid CD, for
example), there isn't any point in using a smaller allocation block
size. Remember that the CD driver will have to read entire 2KB blocks;
if allocation blocks aren't aligned on sector boundaries, it will end up
having to read one or two sectors, extract just the relevant data, and
copy it for the filesystem (which may have to copy it again to user
space). The performance degradation is more noticeable on writable
media, where a simple write turns into read-modify-write. But it does
add up for read-only media.
If you're going to have an HFS wrapper, it would be a good idea to align
the start of the embedded volume on a sector boundary. You can do that
by increasing the allocation block start in the wrapper's MDB. FYI,
older versions of Norton Disk Doctor will incorrectly complain about
such a volume.
> In case of HFS I don't have have
> a choice but for HFS+ it shouldn't be a problem setting the block-size
> to
> 512 even for images greater in size than 32MB, should it ?
> I thought that was the major improvement of HFS+ over HFS.
The allocation block size can be 512 for volume sizes up to 2 terabytes.
When we were developing HFS Plus, we sampled the hard disks of a variety
of users. We recorded the size of every file on their (HFS) hard disk.
We then computed the space savings for various allocation block sizes.
There was a definite "knee" where further decreases in allocation block
size yielded relatively little additional space savings. That knee was
centered at about 4KB, extending to 2KB or 8KB depending on the primary
use of the computer. I was personally surprised at that result; I
assumed we'd continue to see noticeable savings all the way down to 512
byte allocation blocks. As Mac OS X becomes more widely adopted, the
distribution of file sizes will probably change and move the "knee" a
bit.
When we first shipped HFS Plus in Mac OS 8.1, we varied the default
allocation block size from 512 to 4KB, depending on total volume size.
The cutover to 4KB allocation blocks was for volumes 1GB or larger.
Just before Mac OS X came out, we decreased the cutover point so that
volumes 256KB and larger would use 4KB allocation blocks (because early
versions of Mac OS X had a definite performance gain with allocation
blocks that were a multiple of 4KB; the difference is less in current
versions).
Later, in Mac OS 9.1 or 9.2, we added a default allocation block size of
8KB for volumes 220GB or larger. It turned out that the size of the
volume bitmap was becoming a significant factor in writing performance
(specifically, allocating space to files). When the size of the bitmap
got close to or exceeded the size of the disk cache, allocation
performance slowed dramatically. It also tended to push user data out
of the disk cache, leading to a subsequent reduction in hit rates. Of
course this won't affect read-only media, but it may be of interest for
people putting HFS Plus on writable media.
-Mark
From entwicklung@whengenibk.de Thu Apr 11 10:49:50 2002
From: entwicklung@whengenibk.de (Entwicklung)
Date: Thu, 11 Apr 2002 11:49:50 +0200
Subject: Fw: [hfs-user] Problems with HFS+ empty volume...
References: <65E99238-4B0E-11D6-A93A-00039354009A@apple.com>
Message-ID: <000e01c1e13e$3a5c6440$0401a7c0@modemserver>
Hello,
> The point was more that if you're already aligning the data to 2KB
> boundaries (for performance, or because you're making a hybrid CD, for
> example), there isn't any point in using a smaller allocation block
> size. Remember that the CD driver will have to read entire 2KB blocks;
> if allocation blocks aren't aligned on sector boundaries, it will end up
> having to read one or two sectors, extract just the relevant data, and
> copy it for the filesystem (which may have to copy it again to user
> space). The performance degradation is more noticeable on writable
> media, where a simple write turns into read-modify-write. But it does
> add up for read-only media.
I get it... it's ultimately a question of whether one wants to save a bit of
space
at the cost of performance. Thanks for the info - I wasn't even aware that
allocation
block size would affect the performance... and for a CD where space saving
in HFS+
is anyway only a little, I guess performance does play an important role.
> If you're going to have an HFS wrapper, it would be a good idea to align
> the start of the embedded volume on a sector boundary. You can do that
> by increasing the allocation block start in the wrapper's MDB. FYI,
> older versions of Norton Disk Doctor will incorrectly complain about
> such a volume.
How much of effort is involved in having a HFS-Wrapper ? Right now I've just
initialized a pure HFS+ volume without a HFS-Wrapper.... It's working now
btw. ! :)...
>From the previous mailing-list responses I had come to the conclusion that a
wrapper would be necessary since older Macs would then say - The files
cannot be read because it's in HFS+ format -
or something similar. And in case of having no wrapper it would ask if the
CD has to be formatted.
I guess I could also decide not to have a wrapper since if a user decides to
format a CD and clicks 'yes' it's pretty obvious that no data can be
recovered from the disk after formatting a CD-RW for eg.
If I were to have a Wrapper does it mean that I'd have an external HFS
volume in which a HFS+
volume is embedded ? If that is the case - would allocation block no. etc
inside the embedded volume vary relative to the start of the embedded volume
? Do I need a partition map for this? (stupid question probably but was just
wondering if these wouldn't be considered as 'two' volumes)
> When we were developing HFS Plus, we sampled the hard disks of a variety
> of users. We recorded the size of every file on their (HFS) hard disk.
> We then computed the space savings for various allocation block sizes.
> There was a definite "knee" where further decreases in allocation block
> size yielded relatively little additional space savings. That knee was
> centered at about 4KB, extending to 2KB or 8KB depending on the primary
> use of the computer. I was personally surprised at that result; I
> assumed we'd continue to see noticeable savings all the way down to 512
> byte allocation blocks. As Mac OS X becomes more widely adopted, the
> distribution of file sizes will probably change and move the "knee" a
> bit.
Thanks for the insider info - it's quite fascinating to note which factors
and design
considerations do play a role in developing a FS format ....
Regards,
Nandini
From Biswaroop\(External\)"
This is a multi-part message in MIME format.
------=_NextPart_000_0029_01C1E175.2C2797A0
Content-Type: text/plain;
charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Hi everybody,
I was going thru all the mails posted by Nandini and Mark
giving us information about HFS and HFS+ and wrappers.
=20
This is just a inquisitive question. Some days back
it was said HFS + has B- trees where as HFS has
B* trees.=20
Then in older Macs if we read a filesystem of type
HFS+ in a HFS wrapper, do that wrapper also
take care for the internal differences in Data structures.
=20
A more summary of this wrapper concept would
satisfy my interest. Anybody can just give a more
basic understanding of this Wrapper and its functionalities would be =
wonderfull.
Wating for them..
Bye
Biswaroop
The difference between sunrise and=20
sunset lies in the freshness of your
eyes.
--Bisban
------=_NextPart_000_0029_01C1E175.2C2797A0
Content-Type: text/html;
charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Hi everybody,
I was going thru all the mails =
posted by=20
Nandini and Mark
giving us information about HFS =
and HFS+ and=20
wrappers.
This is just a inquisitive =
question.=20
Some days back
it was said HFS + has B- =
trees where=20
as HFS has
B* trees.
Then in older Macs if we =
read a=20
filesystem of type
HFS+ in a HFS wrapper, do =
that wrapper=20
also
take care for the internal =
differences=20
in Data structures.
A more summary of =
this wrapper=20
concept would
satisfy my interest. =
Anybody can=20
just give a more
basic understanding =
of this=20
Wrapper and its functionalities would be wonderfull.
Wating for =
them..
Bye
Biswaroop
The difference between sunrise and =
sunset lies=20
in the freshness of=20
your
eyes.
&n=
bsp; &nb=
sp; =20
--Bisban
------=_NextPart_000_0029_01C1E175.2C2797A0--
From entwicklung@whengenibk.de Thu Apr 11 14:30:17 2002
From: entwicklung@whengenibk.de (Entwicklung)
Date: Thu, 11 Apr 2002 15:30:17 +0200
Subject: [hfs-user] Index / Leaf nodes - help needed..
Message-ID: <000a01c1e15d$06678420$0401a7c0@modemserver>
This is a multi-part message in MIME format.
------=_NextPart_000_0007_01C1E16D.C8CF7AD0
Content-Type: text/plain;
charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Hello Listers,
Unfortunately I seem to be stuck again - I tried =
creating a volume with 601 files. In my case this requires one level of =
leaf-nodes and 3 levels of index nodes (including the root level ). Of =
these 601 files
I'm not able to read 16 files . My tree looks like this :
Root points to IndexNodeA1 and IndexNodeA2.
IndexNodeA1 contains pointer records to IndexNodesB1..11
IndexNodeA2 contains pointer records to IndexNodesB12..17
Here's where the problem seems to arise:
IndexNodeB16 and IndexNodeB17 contain pointers to leaf-nodes L1..11 and =
L12..17 each
Of these the data present in the leaf-nodes L9,L10 and L11 as well as =
that present in L15, L16 and L17seems to getting lost. In short the =
final three pointer records present in the lowest level index node (only =
in the last 2 of the 17 index nodes however) seems to be getting lost. =
The funny part is L15 contains 3 catalog-file records of which the first =
one is again readable but the other two aren't.=20
My point of view:=20
1. As was mentioned in a previous email, since the leaves are gone thru' =
first, all the file-icons are displayed correctly on the Mac. Then the =
index nodes are traversed.=20
2. The problem cannot lie in the root or A level index nodes since part =
of the data pointed to by each of the B-level index nodes get dispayed =
correctly. If there was some mistake in the Ptr records present in level =
A then one would expect that none of the leaf nodes pointed to by a =
particular B-level node appear correctly.
3. I also checked the record offsets at the end of the nodes and the =
keylengths.All my keys are sorted. I don't have any thread records at =
the moment. Under linux hfsutils seems to be able to read all files =
present in L15,L16 and L17 without any problem though my Mac refuses to =
read any other than the first file in L15. (Error -60)
I'm in a fix right now since I don't know what this is due to or how =
exactly to isolate this error. My mode of generating the index nodes is =
quite generic so I would expect an error to either repeat itself more =
frequently or no error to appear... I need some professional help from =
anyone who could take a look at my problem and offer some suggestions. I =
wanted to attach an image but it is a little large to openly post on the =
list to everyone. If anyone would like to take a look at it please let =
me know... would be glad if someone could help.
Regards,
Nandini
=20
=20
------=_NextPart_000_0007_01C1E16D.C8CF7AD0
Content-Type: text/html;
charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Hello Listers,
&nbs=
p; =20
Unfortunately I seem to be stuck again - I tried creating a volume with =
601=20
files. In my case this requires one level of leaf-nodes and 3 levels of =
index=20
nodes (including the root level ). Of these 601 files
I'm not able to read 16 files . My tree =
looks like=20
this :
Root points to IndexNodeA1 and=20
IndexNodeA2.
IndexNodeA1 contains pointer records to =
IndexNodesB1..11
IndexNodeA2 contains pointer records to =
IndexNodesB12..17
Here's where the problem seems to=20
arise:
IndexNodeB16 and IndexNodeB17 contain =
pointers to=20
leaf-nodes L1..11 and L12..17 each
Of these the data present in the =
leaf-nodes L9,L10=20
and L11 as well as that present in L15, L16 and L17seems to getting =
lost. In=20
short the final three pointer records present in the lowest level index =
node=20
(only in the last 2 of the 17 index nodes however) seems to be getting =
lost. The=20
funny part is L15 contains 3 catalog-file records of which the first one =
is=20
again readable but the other two aren't.
My point of view:
1. As was mentioned in a previous =
email, since the=20
leaves are gone thru' first, all the file-icons are =
displayed correctly on=20
the Mac. Then the index nodes are traversed.
2. The problem cannot lie in the root =
or A level=20
index nodes since part of the data pointed to by each of the B-level =
index nodes=20
get dispayed correctly. If there was some mistake in the Ptr =
records=20
present in level A then one would expect that none of the leaf nodes pointed to by a particular B-level =
node appear=20
correctly.
3. I also checked the record offsets at =
the end of=20
the nodes and the keylengths.All my keys are sorted. I don't have any =
thread=20
records at the moment. Under linux hfsutils seems to be able to =
read all=20
files present in L15,L16 and L17 without any problem though my Mac refuses to read any other than the =
first file in=20
L15. (Error -60)
I'm in a fix right now since I don't =
know what this=20
is due to or how exactly to isolate this error. My mode of generating =
the index=20
nodes is quite generic so I would expect an error to either repeat=20
itself more frequently or no error to appear... I need some =
professional=20
help from anyone who could take a look at my problem and offer some =
suggestions. I wanted to attach an image but it is a little large =
to openly=20
post on the list to everyone. If anyone would like to take a look at it =
please=20
let me know... would be glad if someone could help.
Regards,
Nandini
------=_NextPart_000_0007_01C1E16D.C8CF7AD0--
From mday@apple.com Thu Apr 11 18:21:21 2002
From: mday@apple.com (Mark Day)
Date: Thu, 11 Apr 2002 10:21:21 -0700
Subject: [hfs-user] HFS and HFS+ wrapper
In-Reply-To: <002c01c1e147$158bdde0$1c0a0a0a@bisban>
Message-ID: <8AB44373-4D70-11D6-AF9D-00039354009A@apple.com>
On Thursday, April 11, 2002, at 03:53 AM, Biswaroop(External) wrote:
> Then in older Macs if we read a filesystem of type
> HFS+ in a HFS wrapper, do that wrapper also
> take care for the internal differences in Data structures.
>
> A more summary of this wrapper concept would
> satisfy my interest. Anybody can just give a more
> basic understanding of this Wrapper and its functionalities would
> be wonderfull.
A wrapper does NOT allow files on the HFS Plus volume to be accessed as
an HFS volume. It's not like a hybrid ISO/HFS disk where the same
content appears in both directory structures. If we had been able to
make the increased storage efficiency of HFS Plus accessible using HFS
directory structures, we wouldn't have needed to invent a new volume
format...
A wrapper is merely a way to store an HFS Plus volume inside an HFS
volume. It is sort of like the way a DOS disk can have primary
partitions that contain secondary partitions. It is an HFS volume where
some contiguous but otherwise unused space has been set aside to contain
an HFS Plus volume. It helps solve a couple of backwards compatibility
problems:
1. Improve the user experience on systems that don't understand HFS Plus
Consider what would happen if you took a pure HFS Plus volume (no
wrapper) and tried to mount it on a system that doesn't understand HFS
Plus at all, but does understand HFS. The signature fields in the
Volume Header won't match anything the OS knows about (not even HFS).
Most consumer operating systems will display a dialog telling you that
the disk has no recognizable contents. It may even offer to format the
disk for you. That's just asking for the user to accidentally format
the disk and lose all of their data.
If the HFS Plus volume has a wrapper, and the OS understands HFS, the
wrapper mounts as an ordinary HFS volume. The user gets feedback that
the computer recognized their disk, so they know it isn't blank.
But they also won't see the files they are expecting. But since the
wrapper is just an HFS volume, it can contain files. When Apple's code
produces wrappers, it puts a "Read Me" file in the wrapper. When the
wrapper mounts on an HFS-only system, the user will hopefully see and
read that "Read Me" file. It contains text that explains that the
volume is really HFS Plus and that they need a newer version of system
software to be able to use the files on the disk. We think that makes
for a much friendlier user experience than the "Do you want to format
this disk?" dialog they would otherwise get.
2. Allow booting on machines without built-in support for HFS Plus
At the time HFS Plus was first released, no Apple computers had HFS Plus
support in ROM. But we wanted to be able to boot from an HFS Plus
volume. The wrapper makes that possible.
Apple created wrappers contain a tiny System file (the basic part of the
operating system that gets loaded by the boot code in ROM). This isn't
an entire operating system. In fact, it is only enough code to find the
embedded HFS Plus volume and read the System file stored there. The
real System file in the embedded HFS Plus volume contains all the code
to read and write HFS Plus volumes, so the rest of the boot process
proceeds normally, and completely ignorant of the HFS wrapper.
-Mark
From Biswaroop\(External\)"
Hi ,
Some days back , in this list someone had posted
that he is working to enhance the hfsutils for HFS +
filesystem.
Can i get it??
Waiting for ur answers
Bye
Biswaroop
The difference between sunrise and
sunset lies in the freshness of your
eyes.
--Bisban
From entwicklung@whengenibk.de Tue Apr 16 08:39:19 2002
From: entwicklung@whengenibk.de (Entwicklung)
Date: Tue, 16 Apr 2002 09:39:19 +0200
Subject: [hfs-user] Catalog Thread record size ?
Message-ID: <000e01c1e519$d23694a0$0401a7c0@modemserver>
This is a multi-part message in MIME format.
------=_NextPart_000_000B_01C1E52A.954838D0
Content-Type: text/plain;
charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Hello,
I just have a question regarding the size of the HFS Plus - =
Catalog Thread Record specified in the Apple Universal Interfaces =
headers -
typedef UInt16 UniChar;
/* HFSUniStr255 is the Unicode equivalent of Str255 */
struct HFSUniStr255 {
UInt16 length; /* number of unicode =
characters */
UniChar unicode[255]; /* unicode characters */
};
/* HFS Plus catalog thread record -- 264 bytes */
struct HFSPlusCatalogThread {
UInt16 recordType; /* record type */
UInt16 reserved; /* reserved - set =
to zero */
HFSCatalogNodeID parentID; /* parent ID for this =
catalog node */
HFSUniStr255 nodeName; /* name of this catalog =
node (variable length) */
};
typedef struct HFSPlusCatalogThread HFSPlusCatalogThread;
Based on the above declarations shouldn't the size for the HFSPlus =
catalog thread record be 2+2+4 (since CNID's are 4 bytes long ) + 256*2 =
=3D 264+256 instead of 264 as mentioned above ? I think someone probably =
forgot to multiply the 256 by 2 but I just wanted to make sure that is =
an error.
I'd be happy to hear some feedback from the list wrt this.
Best Regards,
Nandini Hengen
------=_NextPart_000_000B_01C1E52A.954838D0
Content-Type: text/html;
charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Hello,
I just=20
have a question regarding the size of the HFS Plus - Catalog Thread =
Record=20
specified in the Apple Universal Interfaces headers -
typedef UInt16 &nb=
sp; =20
UniChar;
/* HFSUniStr255 is the Unicode =
equivalent of Str255=20
*/
struct HFSUniStr255=20
{
UInt16 &n=
bsp; =20
length; =
=20
/* number of unicode characters */
=20
UniChar =
=20
unicode[255]; =
/*=20
unicode characters */
};
/* HFS Plus catalog thread record -- =
264 bytes=20
*/
struct HFSPlusCatalogThread=20
{
UInt16 =20
=
=20
recordType; &n=
bsp; =20
/* record type */
UInt16 =
=20
&=
nbsp;=20
reserved; &nbs=
p; =20
/* reserved - set to zero */
=
HFSCatalogNodeID =20
parentID; &nbs=
p; =20
/* parent ID for this catalog node */
=20
HFSUniStr255 =
nodeName; &nbs=
p; =20
/* name of this catalog node (variable length) */
};
typedef =
struct=20
HFSPlusCatalogThread =20
HFSPlusCatalogThread;
Based on the above declarations =
shouldn't the size=20
for the HFSPlus catalog thread record be 2+2+4 (since CNID's are 4 bytes =
long )=20
+ 256*2 =3D 264+256 instead of 264 as mentioned above ? I think someone =
probably=20
forgot to multiply the 256 by 2 but I just wanted to make sure that is =
an=20
error.
I'd be happy to hear some feedback from =
the list=20
wrt this.
Best Regards,
Nandini Hengen
------=_NextPart_000_000B_01C1E52A.954838D0--
From sibaz@sibaz.com Tue Apr 16 09:22:08 2002
From: sibaz@sibaz.com (Simon Bazley)
Date: Tue, 16 Apr 2002 09:22:08 +0100
Subject: [hfs-user] hfsutils for HFS+
References: <003f01c1e47d$82c0c180$1c0a0a0a@bisban>
Message-ID: <3CBBDF30.82CDFC81@sibaz.com>
I'm not even close to having something working, unless you just want to read sectors off of a diskimage,
But there is a sourceforge project called hfsplus, they were enhancing all the exisitng linux hfs file system stuff. The dates on all the checkins looked quite old so it might even be stable.
Simon
From sibaz@sibaz.com Tue Apr 16 09:57:33 2002
From: sibaz@sibaz.com (Simon Bazley)
Date: Tue, 16 Apr 2002 09:57:33 +0100
Subject: [hfs-user] Catalog Thread record size ?
References: <000e01c1e519$d23694a0$0401a7c0@modemserver>
Message-ID: <3CBBE77D.D565C511@sibaz.com>
Why would you want to multiply 256 by 2? a byte is 1, a char is 1,
therefore 256 chars are 256.
Entwicklung wrote:
> Hello, I just have a question regarding the size of the HFS
> Plus - Catalog Thread Record specified in the Apple Universal
> Interfaces headers - typedef UInt16 UniChar; /*
> HFSUniStr255 is the Unicode equivalent of Str255 */
> struct HFSUniStr255 {
> UInt16 length; /* number of unicode
> characters */
> UniChar unicode[255]; /* unicode characters */
>
> }; /* HFS Plus catalog thread record -- 264 bytes */
> struct HFSPlusCatalogThread {
> UInt16 recordType; /* record type
> */
> UInt16 reserved; /* reserved -
> set to zero */
> HFSCatalogNodeID parentID; /* parent ID for this
> catalog node */
> HFSUniStr255 nodeName; /* name of this
> catalog node (variable length) */
> };
> typedef struct HFSPlusCatalogThread HFSPlusCatalogThread; Based on
> the above declarations shouldn't the size for the HFSPlus catalog
> thread record be 2+2+4 (since CNID's are 4 bytes long ) + 256*2 =
> 264+256 instead of 264 as mentioned above ? I think someone probably
> forgot to multiply the 256 by 2 but I just wanted to make sure that is
> an error. I'd be happy to hear some feedback from the list wrt
> this. Best Regards,Nandini Hengen
From entwicklung@whengenibk.de Tue Apr 16 10:06:00 2002
From: entwicklung@whengenibk.de (Entwicklung)
Date: Tue, 16 Apr 2002 11:06:00 +0200
Subject: [hfs-user] Catalog Thread record size ?
References: <000e01c1e519$d23694a0$0401a7c0@modemserver> <3CBBE77D.D565C511@sibaz.com>
Message-ID: <000801c1e525$ee36e450$0401a7c0@modemserver>
Yes, but if you look at the definitions below : UniChar has been defined as
UInt16 - since Multibyte Unicode is being used for HFS+ - So every
character takes up 2 Bytes in BigEndian format .
So the HFSUniStr255 structure has actually 256 units of 2 Bytes
each -including the length - please correct me if I'm wrong or you think
otherwise.
Regards,
Nandini
----- Original Message -----
From: "Simon Bazley"
To: "Entwicklung"
Cc:
Sent: Tuesday, April 16, 2002 10:57 AM
Subject: Re: [hfs-user] Catalog Thread record size ?
> Why would you want to multiply 256 by 2? a byte is 1, a char is 1,
> therefore 256 chars are 256.
>
> Entwicklung wrote:
>
> > Hello, I just have a question regarding the size of the HFS
> > Plus - Catalog Thread Record specified in the Apple Universal
> > Interfaces headers - typedef UInt16 UniChar; /*
> > HFSUniStr255 is the Unicode equivalent of Str255 */
> > struct HFSUniStr255 {
> > UInt16 length; /* number of unicode
> > characters */
> > UniChar unicode[255]; /* unicode characters */
> >
> > }; /* HFS Plus catalog thread record -- 264 bytes */
> > struct HFSPlusCatalogThread {
> > UInt16 recordType; /* record type
> > */
> > UInt16 reserved; /* reserved -
> > set to zero */
> > HFSCatalogNodeID parentID; /* parent ID for this
> > catalog node */
> > HFSUniStr255 nodeName; /* name of this
> > catalog node (variable length) */
> > };
> > typedef struct HFSPlusCatalogThread HFSPlusCatalogThread; Based on
> > the above declarations shouldn't the size for the HFSPlus catalog
> > thread record be 2+2+4 (since CNID's are 4 bytes long ) + 256*2 =
> > 264+256 instead of 264 as mentioned above ? I think someone probably
> > forgot to multiply the 256 by 2 but I just wanted to make sure that is
> > an error. I'd be happy to hear some feedback from the list wrt
> > this. Best Regards,Nandini Hengen
>
From sibaz@sibaz.com Tue Apr 16 11:04:20 2002
From: sibaz@sibaz.com (Simon Bazley)
Date: Tue, 16 Apr 2002 11:04:20 +0100
Subject: [hfs-user] Catalog Thread record size ?
References: <000e01c1e519$d23694a0$0401a7c0@modemserver> <3CBBE77D.D565C511@sibaz.com> <000801c1e525$ee36e450$0401a7c0@modemserver>
Message-ID: <3CBBF724.BA1AA167@sibaz.com>
I think we're confusing hfs and hfs+, hfs has a fixed name size, thats lots less
that 256 (I should have noticed your 256 wasn't 20 something).
On hfs+ file names are variable, so while it may say something in the book,
thats a maximum size.
The figure they quote as a minimum size for lots of things (due to maximum name
lengths) is 4k.
This is all discussed in detail in the hfs+ tech doc
Entwicklung wrote:
> Yes, but if you look at the definitions below : UniChar has been defined as
> UInt16 - since Multibyte Unicode is being used for HFS+ - So every
> character takes up 2 Bytes in BigEndian format .
>
> So the HFSUniStr255 structure has actually 256 units of 2 Bytes
> each -including the length - please correct me if I'm wrong or you think
> otherwise.
>
> Regards,
> Nandini
>
> ----- Original Message -----
> From: "Simon Bazley"
> To: "Entwicklung"
> Cc:
> Sent: Tuesday, April 16, 2002 10:57 AM
> Subject: Re: [hfs-user] Catalog Thread record size ?
>
> > Why would you want to multiply 256 by 2? a byte is 1, a char is 1,
> > therefore 256 chars are 256.
> >
> > Entwicklung wrote:
> >
> > > Hello, I just have a question regarding the size of the HFS
> > > Plus - Catalog Thread Record specified in the Apple Universal
> > > Interfaces headers - typedef UInt16 UniChar; /*
> > > HFSUniStr255 is the Unicode equivalent of Str255 */
> > > struct HFSUniStr255 {
> > > UInt16 length; /* number of unicode
> > > characters */
> > > UniChar unicode[255]; /* unicode characters */
> > >
> > > }; /* HFS Plus catalog thread record -- 264 bytes */
> > > struct HFSPlusCatalogThread {
> > > UInt16 recordType; /* record type
> > > */
> > > UInt16 reserved; /* reserved -
> > > set to zero */
> > > HFSCatalogNodeID parentID; /* parent ID for this
> > > catalog node */
> > > HFSUniStr255 nodeName; /* name of this
> > > catalog node (variable length) */
> > > };
> > > typedef struct HFSPlusCatalogThread HFSPlusCatalogThread; Based on
> > > the above declarations shouldn't the size for the HFSPlus catalog
> > > thread record be 2+2+4 (since CNID's are 4 bytes long ) + 256*2 =
> > > 264+256 instead of 264 as mentioned above ? I think someone probably
> > > forgot to multiply the 256 by 2 but I just wanted to make sure that is
> > > an error. I'd be happy to hear some feedback from the list wrt
> > > this. Best Regards,Nandini Hengen
> >
From entwicklung@whengenibk.de Tue Apr 16 11:48:12 2002
From: entwicklung@whengenibk.de (Entwicklung)
Date: Tue, 16 Apr 2002 12:48:12 +0200
Subject: [hfs-user] Catalog Thread record size ?
References: <000e01c1e519$d23694a0$0401a7c0@modemserver> <3CBBE77D.D565C511@sibaz.com> <000801c1e525$ee36e450$0401a7c0@modemserver> <3CBBF724.BA1AA167@sibaz.com>
Message-ID: <000c01c1e534$353f3740$0401a7c0@modemserver>
> I think we're confusing hfs and hfs+, hfs has a fixed name size, thats
lots less
> that 256 (I should have noticed your 256 wasn't 20 something).
Yes, HFS has 31 Bytes for the node-name. I was referring only to HFS+ as
previously mentioned. Besides HFS uses MacRoman encoding so I couldn't have
been refering to HFS anyway.
> On hfs+ file names are variable, so while it may say something in the
book,
> thats a maximum size.
>
The 'maximum size' you're referring to is exactly what I wanted to know. And
which book are you referring to ? (the technical notes I presume)
> The figure they quote as a minimum size for lots of things (due to maximum
name
> lengths) is 4k.
>
> This is all discussed in detail in the hfs+ tech doc
Yes - 4k is the minimum catalog node size but not the thread record size.
My question restated:
----------------------
What is this '264' referring to ? It couldn't possibly be Maximum length of
the thread since Maximum length=520 Bytes (when the space requirements of
the individual fields are added up).
It couldn't be minimum length either for the simple reason that if the name
has just one character there's no reason why it should occupy 255 Bytes
considering that the HFS+ names can be of variable size as you mentioned.
Any idea what this 264 refers to then ? I think it is just an error - should
have been 520 instead (max size)... that's what my question was all about...
the technical notes doesn't make a mention of 264 anywhere though the
headers provided by Apple (Universal Interfaces) mention this.
Maybe someone from Apple could help ?
Regards,
Nandini
>
> Entwicklung wrote:
>
> > Yes, but if you look at the definitions below : UniChar has been
defined as
> > UInt16 - since Multibyte Unicode is being used for HFS+ - So every
> > character takes up 2 Bytes in BigEndian format .
> >
> > So the HFSUniStr255 structure has actually 256 units of 2 Bytes
> > each -including the length - please correct me if I'm wrong or you think
> > otherwise.
> >
> > Regards,
> > Nandini
> >
> > ----- Original Message -----
> > From: "Simon Bazley"
> > To: "Entwicklung"
> > Cc:
> > Sent: Tuesday, April 16, 2002 10:57 AM
> > Subject: Re: [hfs-user] Catalog Thread record size ?
> >
> > > Why would you want to multiply 256 by 2? a byte is 1, a char is 1,
> > > therefore 256 chars are 256.
> > >
> > > Entwicklung wrote:
> > >
> > > > Hello, I just have a question regarding the size of the HFS
> > > > Plus - Catalog Thread Record specified in the Apple Universal
> > > > Interfaces headers - typedef UInt16 UniChar; /*
> > > > HFSUniStr255 is the Unicode equivalent of Str255 */
> > > > struct HFSUniStr255 {
> > > > UInt16 length; /* number of unicode
> > > > characters */
> > > > UniChar unicode[255]; /* unicode characters
*/
> > > >
> > > > }; /* HFS Plus catalog thread record -- 264 bytes */
> > > > struct HFSPlusCatalogThread {
> > > > UInt16 recordType; /* record type
> > > > */
> > > > UInt16 reserved; /* reserved -
> > > > set to zero */
> > > > HFSCatalogNodeID parentID; /* parent ID for this
> > > > catalog node */
> > > > HFSUniStr255 nodeName; /* name of this
> > > > catalog node (variable length) */
> > > > };
> > > > typedef struct HFSPlusCatalogThread HFSPlusCatalogThread; Based
on
> > > > the above declarations shouldn't the size for the HFSPlus catalog
> > > > thread record be 2+2+4 (since CNID's are 4 bytes long ) + 256*2 =
> > > > 264+256 instead of 264 as mentioned above ? I think someone probably
> > > > forgot to multiply the 256 by 2 but I just wanted to make sure that
is
> > > > an error. I'd be happy to hear some feedback from the list wrt
> > > > this. Best Regards,Nandini Hengen
> > >
>
From sibaz@sibaz.com Tue Apr 16 12:10:18 2002
From: sibaz@sibaz.com (Simon Bazley)
Date: Tue, 16 Apr 2002 12:10:18 +0100
Subject: [hfs-user] Catalog Thread record size ?
References: <000e01c1e519$d23694a0$0401a7c0@modemserver> <3CBBE77D.D565C511@sibaz.com> <000801c1e525$ee36e450$0401a7c0@modemserver> <3CBBF724.BA1AA167@sibaz.com> <000c01c1e534$353f3740$0401a7c0@modemserver>
Message-ID: <3CBC0699.ECE0BF9A@sibaz.com>
I'm pretty sure this is covered in the tech notes, as you say. I haven't got
time to look at it right now, but I'm pretty sure its discussed, I'll mail the
list when I have a chance to look at it.
Simon
Entwicklung wrote:
> > I think we're confusing hfs and hfs+, hfs has a fixed name size, thats
> lots less
> > that 256 (I should have noticed your 256 wasn't 20 something).
>
> Yes, HFS has 31 Bytes for the node-name. I was referring only to HFS+ as
> previously mentioned. Besides HFS uses MacRoman encoding so I couldn't have
> been refering to HFS anyway.
>
> > On hfs+ file names are variable, so while it may say something in the
> book,
> > thats a maximum size.
> >
>
> The 'maximum size' you're referring to is exactly what I wanted to know. And
> which book are you referring to ? (the technical notes I presume)
>
> > The figure they quote as a minimum size for lots of things (due to maximum
> name
> > lengths) is 4k.
> >
> > This is all discussed in detail in the hfs+ tech doc
>
> Yes - 4k is the minimum catalog node size but not the thread record size.
>
> My question restated:
> ----------------------
> What is this '264' referring to ? It couldn't possibly be Maximum length of
> the thread since Maximum length=520 Bytes (when the space requirements of
> the individual fields are added up).
> It couldn't be minimum length either for the simple reason that if the name
> has just one character there's no reason why it should occupy 255 Bytes
> considering that the HFS+ names can be of variable size as you mentioned.
> Any idea what this 264 refers to then ? I think it is just an error - should
> have been 520 instead (max size)... that's what my question was all about...
> the technical notes doesn't make a mention of 264 anywhere though the
> headers provided by Apple (Universal Interfaces) mention this.
>
> Maybe someone from Apple could help ?
>
> Regards,
> Nandini
>
> >
> > Entwicklung wrote:
> >
> > > Yes, but if you look at the definitions below : UniChar has been
> defined as
> > > UInt16 - since Multibyte Unicode is being used for HFS+ - So every
> > > character takes up 2 Bytes in BigEndian format .
> > >
> > > So the HFSUniStr255 structure has actually 256 units of 2 Bytes
> > > each -including the length - please correct me if I'm wrong or you think
> > > otherwise.
> > >
> > > Regards,
> > > Nandini
> > >
> > > ----- Original Message -----
> > > From: "Simon Bazley"
> > > To: "Entwicklung"
> > > Cc:
> > > Sent: Tuesday, April 16, 2002 10:57 AM
> > > Subject: Re: [hfs-user] Catalog Thread record size ?
> > >
> > > > Why would you want to multiply 256 by 2? a byte is 1, a char is 1,
> > > > therefore 256 chars are 256.
> > > >
> > > > Entwicklung wrote:
> > > >
> > > > > Hello, I just have a question regarding the size of the HFS
> > > > > Plus - Catalog Thread Record specified in the Apple Universal
> > > > > Interfaces headers - typedef UInt16 UniChar; /*
> > > > > HFSUniStr255 is the Unicode equivalent of Str255 */
> > > > > struct HFSUniStr255 {
> > > > > UInt16 length; /* number of unicode
> > > > > characters */
> > > > > UniChar unicode[255]; /* unicode characters
> */
> > > > >
> > > > > }; /* HFS Plus catalog thread record -- 264 bytes */
> > > > > struct HFSPlusCatalogThread {
> > > > > UInt16 recordType; /* record type
> > > > > */
> > > > > UInt16 reserved; /* reserved -
> > > > > set to zero */
> > > > > HFSCatalogNodeID parentID; /* parent ID for this
> > > > > catalog node */
> > > > > HFSUniStr255 nodeName; /* name of this
> > > > > catalog node (variable length) */
> > > > > };
> > > > > typedef struct HFSPlusCatalogThread HFSPlusCatalogThread; Based
> on
> > > > > the above declarations shouldn't the size for the HFSPlus catalog
> > > > > thread record be 2+2+4 (since CNID's are 4 bytes long ) + 256*2 =
> > > > > 264+256 instead of 264 as mentioned above ? I think someone probably
> > > > > forgot to multiply the 256 by 2 but I just wanted to make sure that
> is
> > > > > an error. I'd be happy to hear some feedback from the list wrt
> > > > > this. Best Regards,Nandini Hengen
> > > >
> >
From mday@apple.com Wed Apr 17 00:37:07 2002
From: mday@apple.com (Mark Day)
Date: Tue, 16 Apr 2002 16:37:07 -0700
Subject: [hfs-user] Catalog Thread record size ?
In-Reply-To: <000e01c1e519$d23694a0$0401a7c0@modemserver>
Message-ID:
--Apple-Mail-2--109161683
Content-Transfer-Encoding: 7bit
Content-Type: text/plain;
charset=US-ASCII;
format=flowed
On Tuesday, April 16, 2002, at 12:39 AM, Entwicklung wrote:
> Based on the above declarations shouldn't the size for the HFSPlus
> catalog thread record be 2+2+4 (since CNID's are 4 bytes long ) +
> 256*2 = 264+256 instead of 264 as mentioned above ? I think someone
> probably forgot to multiply the 256 by 2 but I just wanted to make sure
> that is an error.
You're right, it's an error. The correct (maximum) size is 520. The
minimum size would be 10 + 2 * nodeName.length.
-Mark
--Apple-Mail-2--109161683
Content-Transfer-Encoding: 7bit
Content-Type: text/enriched;
charset=US-ASCII
On Tuesday, April 16, 2002, at 12:39 AM, Entwicklung wrote:
ArialBased on the above
declarations shouldn't the size for the HFSPlus catalog thread record
be 2+2+4 (since CNID's are 4 bytes long ) + 256*2 = 264+256 instead of
264 as mentioned above ? I think someone probably forgot to multiply
the 256 by 2 but I just wanted to make sure that is an error.
You're right, it's an error. The correct (maximum) size is 520. The
minimum size would be 10 + 2 * nodeName.length.
-Mark
--Apple-Mail-2--109161683--
From entwicklung@whengenibk.de Thu Apr 18 07:55:16 2002
From: entwicklung@whengenibk.de (Entwicklung)
Date: Thu, 18 Apr 2002 08:55:16 +0200
Subject: [hfs-user] HFS+ volumes : kHFSVolumeUnmountedBit
Message-ID: <000a01c1e6a5$ffa6ac30$0401a7c0@modemserver>
This is a multi-part message in MIME format.
------=_NextPart_000_0007_01C1E6B6.C2A2F3A0
Content-Type: text/plain;
charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Hello Listers,
The HFS+ tech. notes say that the 'Volume attributes' =
field in the volume header has to have Bit 8 set to 1 if the volume was =
correctly flushed when it was mounted or ejected the last time. It also =
mentions that if this is not done it could take an annoyingly long time =
for the ROM-based consistency check (on Mac OS 7.6 and higher) for boot =
volumes.
1) My volume is not a boot volume.
2) I have cleared this bit - set it to 0
3) Inspite of 1) and 2) a smaller HFS+ volume with only one index node =
=3D root gets mounted pretty fast.
4) A larger HFS+ volume (2 levels of index nodes) doesn't get mounted at =
all... my iMac with MacOS 9 just hangs altogether..... I have to remove =
my CD by force and restart.
I assumed this couldn't be an error in the catalog but has something to =
do with the Volume Header since I would have expected to see an error =
dialog instead. Besides this seems to be HFS+ specific since I never =
encountered this kind of problem with HFS.
Does anyone know what this could be due to ? Any suggestions/comments =
would be greatly appreciated.
Regards,
Nandini Hengen
------=_NextPart_000_0007_01C1E6B6.C2A2F3A0
Content-Type: text/html;
charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Hello Listers,
&nbs=
p; =20
The HFS+ tech. notes say that the 'Volume attributes' field in the =
volume header=20
has to have Bit 8 set to 1 if the volume was correctly flushed when it =
was=20
mounted or ejected the last time. It also mentions that if this is not =
done it=20
could take an annoyingly long time for the ROM-based consistency check =
(on Mac=20
OS 7.6 and higher) for boot volumes.
1) My volume is not a boot =
volume.
2) I have cleared this bit - set it to=20
0
3) Inspite of 1) and 2) a smaller HFS+ =
volume with=20
only one index node =3D root gets mounted pretty fast.
4) A larger HFS+ volume (2 levels of =
index nodes)=20
doesn't get mounted at all... my iMac with MacOS 9 just hangs =
altogether..... I=20
have to remove my CD by force and restart.
I assumed this couldn't be an error in =
the catalog=20
but has something to do with the Volume Header since I would have =
expected to=20
see an error dialog instead. Besides this seems to be HFS+ specific =
since I=20
never encountered this kind of problem with HFS.
Does anyone know what this could be due =
to ? Any=20
suggestions/comments would be greatly appreciated.
Regards,
Nandini Hengen
------=_NextPart_000_0007_01C1E6B6.C2A2F3A0--
From entwicklung@whengenibk.de Thu Apr 18 10:16:14 2002
From: entwicklung@whengenibk.de (Entwicklung)
Date: Thu, 18 Apr 2002 11:16:14 +0200
Subject: [hfs-user] HFS+ volumes : kHFSVolumeUnmountedBit
References: <000a01c1e6a5$ffa6ac30$0401a7c0@modemserver>
Message-ID: <001101c1e6b9$b0c7d8f0$0401a7c0@modemserver>
This is a multi-part message in MIME format.
------=_NextPart_000_000E_01C1E6CA.73D7F680
Content-Type: text/plain;
charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Hello everybody,
I found out that it was a problem in the catalog after all - it =
makes absolutely no difference whether I set kHFSVolumeUnmountedBit or =
clear it in my case.
What surprises is that the error wasn't even in the root index node but =
at a lower level index node - I'm surprised that the system hung instead =
of giving me an error dialog as was the case with HFS... but anyway... =
I'm glad this didn't happen before with HFS too otherwise I would have =
had a tough time locating the errors.
Btw this also solves the problem I referred to in my email of 11.04 to =
the list so nobody needs to take a look at my image (not that someone =
wanted to anyway :-)
Regards,
Nandini
----- Original Message -----=20
From: Entwicklung=20
To: hfs-user@lists.mars.org=20
Cc: studentdev@lists.apple.com=20
Sent: Thursday, April 18, 2002 8:55 AM
Subject: [hfs-user] HFS+ volumes : kHFSVolumeUnmountedBit
Hello Listers,
The HFS+ tech. notes say that the 'Volume =
attributes' field in the volume header has to have Bit 8 set to 1 if the =
volume was correctly flushed when it was mounted or ejected the last =
time. It also mentions that if this is not done it could take an =
annoyingly long time for the ROM-based consistency check (on Mac OS 7.6 =
and higher) for boot volumes.
1) My volume is not a boot volume.
2) I have cleared this bit - set it to 0
3) Inspite of 1) and 2) a smaller HFS+ volume with only one index node =
=3D root gets mounted pretty fast.
4) A larger HFS+ volume (2 levels of index nodes) doesn't get mounted =
at all... my iMac with MacOS 9 just hangs altogether..... I have to =
remove my CD by force and restart.
I assumed this couldn't be an error in the catalog but has something =
to do with the Volume Header since I would have expected to see an error =
dialog instead. Besides this seems to be HFS+ specific since I never =
encountered this kind of problem with HFS.
=20
Does anyone know what this could be due to ? Any suggestions/comments =
would be greatly appreciated.
Regards,
Nandini Hengen
------=_NextPart_000_000E_01C1E6CA.73D7F680
Content-Type: text/html;
charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Hello everybody,
I found=20
out that it was a problem in the catalog after all - it makes absolutely =
no=20
difference whether I set kHFSVolumeUnmountedBit or clear it in my=20
case.
What surprises is that the error wasn't =
even in the=20
root index node but at a lower level index node - I'm surprised that the =
system=20
hung instead of giving me an error dialog as was the case with HFS... =
but=20
anyway... I'm glad this didn't happen before with HFS too otherwise I =
would have=20
had a tough time locating the errors.
Btw this also solves the problem I =
referred=20
to in my email of 11.04 to the list so nobody needs to take a look =
at my=20
image (not that someone wanted to anyway :-)
Regards,
Nandini
----- Original Message -----
From:=20
Entwicklung
To: hfs-user@lists.mars.org
Cc: studentdev@lists.apple.com =
Sent: Thursday, April 18, 2002 =
8:55=20
AM
Subject: [hfs-user] HFS+ =
volumes :=20
kHFSVolumeUnmountedBit
Hello Listers,
&nbs=
p; =20
The HFS+ tech. notes say that the 'Volume attributes' field in the =
volume=20
header has to have Bit 8 set to 1 if the volume was correctly flushed =
when it=20
was mounted or ejected the last time. It also mentions that if this is =
not=20
done it could take an annoyingly long time for the ROM-based =
consistency check=20
(on Mac OS 7.6 and higher) for boot volumes.
1) My volume is not a boot =
volume.
2) I have cleared this bit - set it =
to=20
0
3) Inspite of 1) and 2) a smaller =
HFS+ volume=20
with only one index node =3D root gets mounted pretty =
fast.
4) A larger HFS+ volume (2 levels of =
index nodes)=20
doesn't get mounted at all... my iMac with MacOS 9 just hangs =
altogether.....=20
I have to remove my CD by force and restart.
I assumed this couldn't be an error =
in the=20
catalog but has something to do with the Volume Header since I would =
have=20
expected to see an error dialog instead. Besides this seems to be HFS+ =
specific since I never encountered this kind of problem with =
HFS.
Does anyone know what this could be =
due to ? Any=20
suggestions/comments would be greatly appreciated.
Regards,
Nandini Hengen
------=_NextPart_000_000E_01C1E6CA.73D7F680--
From entwicklung@whengenibk.de Thu Apr 18 14:27:23 2002
From: entwicklung@whengenibk.de (Entwicklung)
Date: Thu, 18 Apr 2002 15:27:23 +0200
Subject: [hfs-user] Help needed...
Message-ID: <000e01c1e6dc$c7968a90$0401a7c0@modemserver>
This is a multi-part message in MIME format.
------=_NextPart_000_000B_01C1E6ED.89BFF1A0
Content-Type: text/plain;
charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Hello listers,
I've encountered a problem in my HFS directory =
structure which I have tried to elaborate below... please do take a look =
at it and see if some plausible reason strikes you.
I have a file File-X say under Root. Under Root I also have a folder =
Folder-X inside which I have another file of the same name i.e. File-X =
and another file File-Y.=20
File-X is a pdf file of size 42MB and File-Y is a simple text file only =
4kB in size.
All icons get correctly displayed from my CD so I presume all the leaf =
nodes of my catalog B-Tree are getting iterated through (since the icons =
get set based on the filetype and creator fields).
The problem I'm facing is that File-Y (within Folder-X) is readable, =
File-X under Root is readable but when I try to open File-X which is =
under Folder-X Acrobat seems to go into sleep mode.=20
What could this possible be due to ? I first thought the references =
maintained to the file extents (or file size)
was wrong... but it seems to be right... the start block as well as the =
block count (in the leaf nodes) seem to be all right... what else could =
cause the icon to get displayed but not allow the file to be opened ?=20
- The file is correctly written (twice at two different locations) and =
readable the first time.
- The start-block and block count seems to be right for both.=20
- Another file written at the same level is readable.
Could it have something to do with the size of the file ? Please help if =
you have any idea what could be causing this..
Regards,
Nandini Hengen
=20
------=_NextPart_000_000B_01C1E6ED.89BFF1A0
Content-Type: text/html;
charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Hello listers,
&nbs=
p; I've=20
encountered a problem in my HFS directory structure which I have tried =
to=20
elaborate below... please do take a look at it and see if some plausible =
reason=20
strikes you.
I have a file File-X say under =
Root. Under=20
Root I also have a folder Folder-X inside which I have another =
file of=20
the same name i.e. File-X and another file File-Y.
File-X is a pdf file of size 42MB =
and File-Y=20
is a simple text file only 4kB in size.
All icons get correctly displayed from =
my CD so I=20
presume all the leaf nodes of my catalog B-Tree are getting iterated =
through=20
(since the icons get set based on the filetype and creator =
fields).
The problem I'm facing is that File-Y =
(within=20
Folder-X) is readable, File-X under Root is readable but when I try to =
open=20
File-X which is under Folder-X Acrobat seems to go into sleep =
mode.=20
What could this possible be due to ? I =
first=20
thought the references maintained to the file extents (or file=20
size)
was wrong... but it seems to be =
right... the start=20
block as well as the block count (in the leaf nodes) seem to be all =
right... what else could cause the icon to get displayed but not =
allow the=20
file to be opened ?
- The file is correctly written (twice =
at two=20
different locations) and readable the first time.
- The start-block and block count seems =
to be right=20
for both.
- Another file written at the same =
level is=20
readable.
Could it have something to do with the =
size of the=20
file ? Please help if you have any idea what could be causing=20
this..
Regards,
Nandini Hengen
------=_NextPart_000_000B_01C1E6ED.89BFF1A0--
From entwicklung@whengenibk.de Fri Apr 19 12:23:15 2002
From: entwicklung@whengenibk.de (Entwicklung)
Date: Fri, 19 Apr 2002 13:23:15 +0200
Subject: [hfs-user] pdf files on Mac-OS 9
Message-ID: <002801c1e794$9a43b870$0401a7c0@modemserver>
This is a multi-part message in MIME format.
------=_NextPart_000_0025_01C1E7A5.5CDFB770
Content-Type: text/plain;
charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Hello Listers,
I have a CD-Volume (HFS) with two levels of files in =
a directory i.e. at the topmost level (under root) and inside a =
directory present in root. The same pdf file when present at the higher =
level is readable directly from the CD but the file present within the =
directory is not. This problem arises only for Acrobat reader =
documents.. it works fine for text f=EDles.... besides dragging and =
droppping these lower level files onto my desktop from the CD enables me =
to read them as required.
What could this be due to ? Could this be some problem with the =
filesystem format or does it rather have to do with Acrobat Reader for =
Mac OS?
Any tips would be appreciated.
Regards,
Nandini Hengen
------=_NextPart_000_0025_01C1E7A5.5CDFB770
Content-Type: text/html;
charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Hello Listers,
&nbs=
p; =20
I have a CD-Volume (HFS) with two levels of files in a directory i.e. at =
the=20
topmost level (under root) and inside a directory present in root. The =
same pdf=20
file when present at the higher level is readable directly from the CD =
but the=20
file present within the directory is not. This problem arises only for =
Acrobat=20
reader documents.. it works fine for text f=EDles.... besides dragging =
and=20
droppping these lower level files onto my desktop from the CD enables me =
to read=20
them as required.
What could this be due to ? Could this =
be some=20
problem with the filesystem format or does it rather have to do with =
Acrobat=20
Reader for Mac OS?
Any tips would be =
appreciated.
Regards,
Nandini =
Hengen
------=_NextPart_000_0025_01C1E7A5.5CDFB770--
From entwicklung@whengenibk.de Sat Apr 20 21:45:22 2002
From: entwicklung@whengenibk.de (Entwicklung)
Date: Sat, 20 Apr 2002 22:45:22 +0200
Subject: [hfs-user] Re: pdf files on Mac-OS 9
References: <002801c1e794$9a43b870$0401a7c0@modemserver>
Message-ID: <000501c1e8ac$4add4a80$0401a7c0@modemserver>
Hello,
My problem is solved now ... I realised it had to have something to
do with the folder threads - i.e. that the thread records didn't maintain
correct references to the folders.... was quite a silly error actually
.... the nodename[0] field which holds the length of the nodename (in the
folder and its thread didn't correspond to each other due to a small bug in
my program) ... so though the file and the icon got displayed correctly and
the data could be accessed, acrobat apparently tries relocating its way
down the tree starting from root.
One surprising thing I noticed is that I didn't have this problem for jpg
files - probably the graphics application which is launched on Mac OS
functions slightly differently as compared to Acrobat.....
dunno in what way although...good news is it works now anyway !
Regards,
Nandini Hengen
----- Original Message -----
From: "Steve Sisak"
To: "Entwicklung" ;
Sent: Friday, April 19, 2002 2:14 PM
Subject: Re: pdf files on Mac-OS 9
> At 1:23 PM +0200 4/19/02, Entwicklung wrote:
> >What could this be due to ? Could this be some problem with the
filesystem
> >format or does it rather have to do with Acrobat Reader for Mac OS?
>
> This is not a Darwin issue, but it's probably that the HFS file type
> is not set to and therefor the file can't be opened by Acrobat
> because it isn't recognized as a PDF file.
>
> When you copy the file, PC File Exchange treats it as a Non-Mac file
> (because the type isn't set) and applies a type/creator based on the
> file's extension which allows the copy to be opened by Acrobat -- it
> probably doesn't matter where you copy.
>
> (Note that the creator is not important, but most pre-X Mac
> applications will not open a file with an incorrect type --
> extensions have no significance pre-X)
>
> -Steve
> _______________________________________________
> darwin-development mailing list | darwin-development@lists.apple.com
> Help/Unsubscribe/Archives:
http://www.lists.apple.com/mailman/listinfo/darwin-development
> Do not post admin requests to the list. They will be ignored.
From entwicklung@whengenibk.de Sun Apr 21 15:44:03 2002
From: entwicklung@whengenibk.de (Entwicklung)
Date: Sun, 21 Apr 2002 16:44:03 +0200
Subject: [hfs-user] HFS Maximum Image Size
Message-ID: <002801c1e942$fba7dc40$0401a7c0@modemserver>
This is a multi-part message in MIME format.
------=_NextPart_000_0025_01C1E953.BEC5B570
Content-Type: text/plain;
charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Hello Listers,
The maximum size of an HFS-volume seems to be =
65535*65535 =3D 3.99 GB. (since the respective fields in the MDB are =
UInt16's). Does this mean that to store a file of size 4.7GB I would =
have to necessarily go in for HFS+ or is this possible with HFS somehow =
?
Regards,
Nandini Hengen=20
------=_NextPart_000_0025_01C1E953.BEC5B570
Content-Type: text/html;
charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Hello Listers,
&nbs=
p; =20
The maximum size of an HFS-volume seems to be 65535*65535 =3D 3.99 GB. =
(since the=20
respective fields in the MDB are UInt16's). Does this mean that to store =
a file of size 4.7GB I would have to necessarily go in for =
HFS+ or is=20
this possible with HFS somehow=20
?
Regards,
Nandini =
Hengen
------=_NextPart_000_0025_01C1E953.BEC5B570--
From mday@apple.com Mon Apr 22 21:35:56 2002
From: mday@apple.com (Mark Day)
Date: Mon, 22 Apr 2002 13:35:56 -0700
Subject: [hfs-user] HFS Maximum Image Size
In-Reply-To: <002801c1e942$fba7dc40$0401a7c0@modemserver>
Message-ID: <8BF918CE-5630-11D6-A41D-00039354009A@apple.com>
--Apple-Mail-3-398366786
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
charset=ISO-8859-1;
format=flowed
The maximum file size on HFS volumes is 2GB-1 (the maximum value in a=20
signed 32-bit integer). See struct HFSCatalogFile.
The maximum volume size is theoretically just under 256TB (actually,=20
65535 allocation blocks * (4G-512) bytes per allocation block). The=20
allocation block size is an unsigned 32-bit integer, but must be a=20
multiple of 512. I don't know of any implementation that supports HFS=20=
volumes 2TB or larger; some versions have much smaller limits (eg., 2GB=20=
or 4GB). Many implementations use 32-bit integers (signed or unsigned)=20=
for offsets into the volume, or as block numbers (assuming 512 bytes per=20=
block).
-Mark
On Sunday, April 21, 2002, at 07:44 AM, Entwicklung wrote:
> =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 The maximum =
size of an HFS-volume seems to be=20
> 65535*65535 =3D 3.99 GB. (since the respective fields in the MDB are=20=
> UInt16's). Does this mean that to store a=A0file of size=A04.7GB I =
would=20
> have to necessarily go in for HFS+ or is this possible with=20
> HFS=A0somehow ?
--Apple-Mail-3-398366786
Content-Transfer-Encoding: quoted-printable
Content-Type: text/enriched;
charset=ISO-8859-1
The maximum file size on HFS volumes is 2GB-1 (the maximum value in a
signed 32-bit integer). See struct HFSCatalogFile.
The maximum volume size is theoretically just under 256TB (actually,
65535 allocation blocks * (4G-512) bytes per allocation block). The
allocation block size is an unsigned 32-bit integer, but must be a
multiple of 512. I don't know of any implementation that supports HFS
volumes 2TB or larger; some versions have much smaller limits (eg.,
2GB or 4GB). Many implementations use 32-bit integers (signed or
unsigned) for offsets into the volume, or as block numbers (assuming
512 bytes per block).
-Mark
On Sunday, April 21, 2002, at 07:44 AM, Entwicklung wrote:
Arial=A0=A0=A0=A0=A0=A0=A0=A0=
=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0
The maximum size of an HFS-volume seems to be 65535*65535 =3D 3.99 GB.
(since the respective fields in the MDB are UInt16's). Does this mean
that to store a=A0file of size=A04.7GB I would have to necessarily go in
for HFS+ or is this possible with HFS=A0somehow ?
=
--Apple-Mail-3-398366786--
From entwicklung@whengenibk.de Tue Apr 23 06:37:22 2002
From: entwicklung@whengenibk.de (Entwicklung)
Date: Tue, 23 Apr 2002 07:37:22 +0200
Subject: [hfs-user] HFS Maximum Image Size
References: <8BF918CE-5630-11D6-A41D-00039354009A@apple.com>
Message-ID: <003101c1ea88$f23eac50$0401a7c0@modemserver>
This is a multi-part message in MIME format.
------=_NextPart_000_002E_01C1EA99.B4DF3F30
Content-Type: text/plain;
charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Hello,
I made a mistake . I had thought that drNumAlBlocks and =
drAlBlkSize in the MDB were both of type UInt16 but drAlBlkSize happens =
to be of size 4Bytes - I didn't see that.
Thanks!
-Nandini
----- Original Message -----=20
From: Mark Day=20
To: Entwicklung=20
Cc: hfs-user@lists.mars.org=20
Sent: Monday, April 22, 2002 10:35 PM
Subject: Re: [hfs-user] HFS Maximum Image Size
The maximum file size on HFS volumes is 2GB-1 (the maximum value in a =
signed 32-bit integer). See struct HFSCatalogFile.
The maximum volume size is theoretically just under 256TB (actually, =
65535 allocation blocks * (4G-512) bytes per allocation block). The =
allocation block size is an unsigned 32-bit integer, but must be a =
multiple of 512. I don't know of any implementation that supports HFS =
volumes 2TB or larger; some versions have much smaller limits (eg., 2GB =
or 4GB). Many implementations use 32-bit integers (signed or unsigned) =
for offsets into the volume, or as block numbers (assuming 512 bytes per =
block).
-Mark
On Sunday, April 21, 2002, at 07:44 AM, Entwicklung wrote:
The maximum size of an HFS-volume seems to be =
65535*65535 =3D 3.99 GB. (since the respective fields in the MDB are =
UInt16's). Does this mean that to store a file of size 4.7GB I would =
have to necessarily go in for HFS+ or is this possible with HFS somehow =
?
------=_NextPart_000_002E_01C1EA99.B4DF3F30
Content-Type: text/html;
charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Hello,
I made a=20
mistake . I had thought that drNumAlBlocks and drAlBlkSize in the MDB =
were both=20
of type UInt16 but drAlBlkSize happens to be of size 4Bytes - I didn't =
see=20
that.
Thanks!
-Nandini
----- Original Message -----
From:=20
Mark Day =
Cc: hfs-user@lists.mars.org
Sent: Monday, April 22, 2002 =
10:35=20
PM
Subject: Re: [hfs-user] HFS =
Maximum Image=20
Size
The maximum file size on HFS volumes is 2GB-1 (the =
maximum=20
value in a signed 32-bit integer). See struct =
HFSCatalogFile.
The=20
maximum volume size is theoretically just under 256TB (actually, 65535 =
allocation blocks * (4G-512) bytes per allocation block). The =
allocation block=20
size is an unsigned 32-bit integer, but must be a multiple of 512. I =
don't=20
know of any implementation that supports HFS volumes 2TB or larger; =
some=20
versions have much smaller limits (eg., 2GB or 4GB). Many =
implementations use=20
32-bit integers (signed or unsigned) for offsets into the volume, or =
as block=20
numbers (assuming 512 bytes per block).
-Mark
On Sunday, =
April=20
21, 2002, at 07:44 AM, Entwicklung wrote:
&nb=
sp; =20
The maximum size of an HFS-volume seems to be 65535*65535 =3D 3.99 =
GB. (since=20
the respective fields in the MDB are UInt16's). Does this mean that =
to store=20
a file of size 4.7GB I would have to necessarily go in for =
HFS+ or=20
is this possible with HFS somehow=20
?
------=_NextPart_000_002E_01C1EA99.B4DF3F30--
From entwicklung@whengenibk.de Tue Apr 23 06:53:11 2002
From: entwicklung@whengenibk.de (Entwicklung)
Date: Tue, 23 Apr 2002 07:53:11 +0200
Subject: [hfs-user] HFS Maximum Image Size
References: <8BF918CE-5630-11D6-A41D-00039354009A@apple.com>
Message-ID: <004e01c1ea8b$3001e9b0$0401a7c0@modemserver>
This is a multi-part message in MIME format.
------=_NextPart_000_0046_01C1EA9B.EA272930
Content-Type: text/plain;
charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
It would interest me as to why the file size is stored in a signed =
32-bit integer and not an unsigned int 32- wouldn't this provide for =
larger files then ? (4GB - 1)
Regards,
Nandini Hengen
----- Original Message -----=20
From: Mark Day=20
To: Entwicklung=20
Cc: hfs-user@lists.mars.org=20
Sent: Monday, April 22, 2002 10:35 PM
Subject: Re: [hfs-user] HFS Maximum Image Size
The maximum file size on HFS volumes is 2GB-1 (the maximum value in a =
signed 32-bit integer). See struct HFSCatalogFile.
The maximum volume size is theoretically just under 256TB (actually, =
65535 allocation blocks * (4G-512) bytes per allocation block). The =
allocation block size is an unsigned 32-bit integer, but must be a =
multiple of 512. I don't know of any implementation that supports HFS =
volumes 2TB or larger; some versions have much smaller limits (eg., 2GB =
or 4GB). Many implementations use 32-bit integers (signed or unsigned) =
for offsets into the volume, or as block numbers (assuming 512 bytes per =
block).
-Mark
On Sunday, April 21, 2002, at 07:44 AM, Entwicklung wrote:
The maximum size of an HFS-volume seems to be =
65535*65535 =3D 3.99 GB. (since the respective fields in the MDB are =
UInt16's). Does this mean that to store a file of size 4.7GB I would =
have to necessarily go in for HFS+ or is this possible with HFS somehow =
?
------=_NextPart_000_0046_01C1EA9B.EA272930
Content-Type: text/html;
charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
It would interest me as to why the file =
size is=20
stored in a signed 32-bit integer and not an unsigned int 32- wouldn't =
this=20
provide for larger files then ? (4GB - 1)
Regards,
Nandini Hengen
----- Original Message -----
From:=20
Mark Day =
Cc: hfs-user@lists.mars.org
Sent: Monday, April 22, 2002 =
10:35=20
PM
Subject: Re: [hfs-user] HFS =
Maximum Image=20
Size
The maximum file size on HFS volumes is 2GB-1 (the =
maximum=20
value in a signed 32-bit integer). See struct =
HFSCatalogFile.
The=20
maximum volume size is theoretically just under 256TB (actually, 65535 =
allocation blocks * (4G-512) bytes per allocation block). The =
allocation block=20
size is an unsigned 32-bit integer, but must be a multiple of 512. I =
don't=20
know of any implementation that supports HFS volumes 2TB or larger; =
some=20
versions have much smaller limits (eg., 2GB or 4GB). Many =
implementations use=20
32-bit integers (signed or unsigned) for offsets into the volume, or =
as block=20
numbers (assuming 512 bytes per block).
-Mark
On Sunday, =
April=20
21, 2002, at 07:44 AM, Entwicklung wrote:
&nb=
sp; =20
The maximum size of an HFS-volume seems to be 65535*65535 =3D 3.99 =
GB. (since=20
the respective fields in the MDB are UInt16's). Does this mean that =
to store=20
a file of size 4.7GB I would have to necessarily go in for =
HFS+ or=20
is this possible with HFS somehow=20
?
------=_NextPart_000_0046_01C1EA9B.EA272930--
From Biswaroop\(External\)"
Hi all,
I am just wondering about the Max Volume size for a
HFS volume.
Theretically
it should be..
2^16 * 2^32(it is a multiple of 512)= 2^48
2^30 = 1GB
Therefore
2^18 GB is the maximum.(Isn't it??)
regards
Biswaroop
The difference between sunrise and
sunset lies in the freshness of your
eyes.
--Bisban
From entwicklung@whengenibk.de Tue Apr 23 08:38:13 2002
From: entwicklung@whengenibk.de (Entwicklung)
Date: Tue, 23 Apr 2002 09:38:13 +0200
Subject: Fw: [hfs-user] (no subject)
Message-ID: <000f01c1ea99$d3355c30$0401a7c0@modemserver>
----- Original Message -----
From: "Entwicklung"
To: "Biswaroop(External)"
Sent: Tuesday, April 23, 2002 9:37 AM
Subject: Re: [hfs-user] (no subject)
> Hi Biswaroop,
> It's (2^16 -1)*(2^32 - 1) - since in a
2s-complement
> representation n-bytes(unsigned) can store a maximum positive value of
> (2^n - 1). This is also why the maximum no. of allocation blocks is 65535
> and not 65536(2^16) since otherwise it would result in an overflow. Signed
> integers - SInt8 for eg. can hold values ranging from -128 (-2^(n-1)) to
+127
> (2^(n-1) - 1).
>
> Hope this helps !
>
> Regards,
> Nandini
>
> ----- Original Message -----
> From: "Biswaroop(External)"
> To:
> Sent: Tuesday, April 23, 2002 8:53 AM
> Subject: [hfs-user] (no subject)
>
>
> > Hi all,
> >
> > I am just wondering about the Max Volume size for a
> > HFS volume.
> > Theretically
> > it should be..
> > 2^16 * 2^32(it is a multiple of 512)= 2^48
> > 2^30 = 1GB
> > Therefore
> > 2^18 GB is the maximum.(Isn't it??)
> >
> > regards
> > Biswaroop
> >
> >
> >
> > The difference between sunrise and
> > sunset lies in the freshness of your
> > eyes.
> > --Bisban
>
From entwicklung@whengenibk.de Thu Apr 25 07:06:43 2002
From: entwicklung@whengenibk.de (Entwicklung)
Date: Thu, 25 Apr 2002 08:06:43 +0200
Subject: [hfs-user] Desktop View
Message-ID: <000a01c1ec1f$62118060$0401a7c0@modemserver>
This is a multi-part message in MIME format.
------=_NextPart_000_0007_01C1EC30.23573E30
Content-Type: text/plain;
charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Hello,
I need some help.
I'd like to know what part of the HFS format is responsible for how =
icons on an external CD-volume appear on the desktop of Mac OS 9. The =
desktop database holds the icon info but where is info. like=20
Window-sizing on the Mac, no. of icons per row, spacing of icons etc. =
stored ? Is this stored on the hard-disk of the Mac or is there some way =
in which I can get this to be stored on my CD as well ? Is this part of =
the desktop database too ?
The situation is as follows - when I insert my HFS-CD into my drive and =
click on the CD-symbol a window opens up displaying the icons for all =
the files present on the CD but they are not spaced properly and the =
view doesn't look all that good - Is there some way in which I can =
display these properly ? ..ie. say 'n' icons in one row etc ? Sometimes =
there are around 30 icons displayed for around 100 files on my CD... =
then a lot of empty space is displayed - which could mislead the user to =
think that no more files are present - and then the remaining 70 =
file-icons suddenly show up.
I presume this doesn't have to be stored on the external HFS-volume but =
rather has something to do with my Mac-OS settings... but I'm not too =
sure. I'd appreciate it if someone could tell me which part is =
responsible for such things ? I'm not creating a desktop DB at the =
moment but this looks really bad and I'd like to change it if I can i.e. =
if this can be overcome somehow without having a desktop database on my =
CD.
TIA,
Nandini
********** It's not easy to find happiness in ourselves and it's not =
possible to find it elsewhere ************
------=_NextPart_000_0007_01C1EC30.23573E30
Content-Type: text/html;
charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Hello,
I need some=20
help.
I'd like to know what part of the HFS =
format is=20
responsible for how icons on an external CD-volume appear on the desktop =
of Mac=20
OS 9. The desktop database holds the icon info but where is info. like=20
Window-sizing on the Mac, no. of icons =
per row,=20
spacing of icons etc. stored ? Is this stored on the hard-disk of the =
Mac or=20
is there some way in which I can get this to be stored on my CD as =
well ?=20
Is this part of the desktop database too ?
The situation is as follows - when I =
insert my=20
HFS-CD into my drive and click on the CD-symbol a window opens up=20
displaying the icons for all the files present on the CD but they are =
not spaced=20
properly and the view doesn't look all that good - Is there some way in =
which I=20
can display these properly ? =
..ie.=20
say 'n' icons in one row etc ? Sometimes there are around 30 icons=20
displayed for around 100 files on my CD... then a lot of empty space is=20
displayed - which could mislead the user to think that no more files are =
present=20
- and then the remaining 70 file-icons suddenly show up.
I presume this doesn't have to be =
stored on the=20
external HFS-volume but rather has something to do with my Mac-OS =
settings...=20
but I'm not too sure. I'd appreciate it if someone could tell me which =
part is=20
responsible for such things ? I'm not creating a desktop DB at the =
moment but=20
this looks really bad and I'd like to change it if I can i.e. if =
this can=20
be overcome somehow without having a desktop database on my=20
CD.
TIA,
Nandini
********** It's not easy to find =
happiness in=20
ourselves and it's not possible to find it elsewhere=20
************
------=_NextPart_000_0007_01C1EC30.23573E30--
From pwd@apple.com Thu Apr 25 07:41:42 2002
From: pwd@apple.com (Patrick Dirks)
Date: Wed, 24 Apr 2002 23:41:42 -0700
Subject: [hfs-user] Desktop View
In-Reply-To: <000a01c1ec1f$62118060$0401a7c0@modemserver>
Message-ID: <80EF9C03-5817-11D6-8FE2-003065A0E6DE@apple.com>
Hi Nandini,
The information the Finder uses to organize a window's layout is stored
in the Finder Info for the folder in question (where things like the
scroll position, view organization etc. are stored) and the Finder Info
for the individual items (each of which stores the position for the
item, for instance).
The Finder will set the layout information for a file if it sees the
"Inited" flag in the FinderInfo's flags field cleared. Once a position
in the window has been assigned and the Finder has done its housekeeping
like reading application icons out of an application's resource fork the
Finder sets the "Inited" bit to prevent doing the same work again in the
future.
The layout of this Finder Info field is contained in the various "Inside
Macintosh" volumes, as well as header files like "Files.h". It's
probably on-line in some technote on Apple's web site, too.
Hope that helps,
-Patrick.
On Wednesday, April 24, 2002, at 11:06 PM, Entwicklung wrote:
> Hello,
> I need some help.
> I'd like to know what part of the HFS format is responsible for how
> icons on an external CD-volume appear on the desktop of Mac OS 9. The
> desktop database holds the icon info but where is info. like
> Window-sizing on the Mac, no. of icons per row, spacing of icons etc.
> stored ? Is this stored on the hard-disk of the Mac or is there some
> way in which I can get this to be stored on my CD as well ? Is this
> part of the desktop database too ?
>
> The situation is as follows - when I insert my HFS-CD into my drive and
> click on the CD-symbol a window opens up displaying the icons for all
> the files present on the CD but they are not spaced properly and the
> view doesn't look all that good - Is there some way in which I can
> display these properly ? ..ie. say 'n' icons in one row etc ? Sometimes
> there are around 30 icons displayed for around 100 files on my CD...
> then a lot of empty space is displayed - which could mislead the user
> to think that no more files are present - and then the remaining 70
> file-icons suddenly show up.
>
> I presume this doesn't have to be stored on the external HFS-volume but
> rather has something to do with my Mac-OS settings... but I'm not too
> sure. I'd appreciate it if someone could tell me which part is
> responsible for such things ? I'm not creating a desktop DB at the
> moment but this looks really bad and I'd like to change it if I can
> i.e. if this can be overcome somehow without having a desktop database
> on my CD.
>
> TIA,
> Nandini
>
>
>
> ********** It's not easy to find happiness in ourselves and it's not
> possible to find it elsewhere ************
From Biswaroop\(External\)"
Hi ,
I want to make a HFS volume readonly.
I am setting the flag in mdb.drAtrb to
mdb.drAtrb | = 0x4000 ( As said in Inside Macintosh)
Bit Meaning
15 Set if th volume is Locked by Software.
After creating a Image of such a Volume.
I am mounting it with a FreeWare application in Windows which can mount HFS
volumes.
But , I can still add files to that volume through this
software and delete them too.
That shows the volume is not Locked.
So, anything else I should do to Volume parameters
to make that Volume represent a ReadOnly one??
Waiting for ur Inputs.
Regards
Biswaroop
The difference between sunrise and
sunset lies in the freshness of your
eyes.
--Bisban
From entwicklung@whengenibk.de Fri Apr 26 12:38:58 2002
From: entwicklung@whengenibk.de (Entwicklung)
Date: Fri, 26 Apr 2002 13:38:58 +0200
Subject: [hfs-user] To make a Readonly HFS Volume
References: <008401c1ed14$06206640$1c0a0a0a@bisban>
Message-ID: <000801c1ed16$f54a1160$0401a7c0@modemserver>
Wouldn't setting bit 15 give 0x8000 ??? numbering the 16 bits from 0..15
i.e.
- Nandini
----- Original Message -----
From: "Biswaroop(External)"
To:
Sent: Friday, April 26, 2002 1:17 PM
Subject: [hfs-user] To make a Readonly HFS Volume
> Hi ,
>
> I want to make a HFS volume readonly.
> I am setting the flag in mdb.drAtrb to
>
> mdb.drAtrb | = 0x4000 ( As said in Inside Macintosh)
>
> Bit Meaning
> 15 Set if th volume is Locked by Software.
>
> After creating a Image of such a Volume.
> I am mounting it with a FreeWare application in Windows which can mount
HFS
> volumes.
> But , I can still add files to that volume through this
> software and delete them too.
> That shows the volume is not Locked.
> So, anything else I should do to Volume parameters
> to make that Volume represent a ReadOnly one??
>
> Waiting for ur Inputs.
>
> Regards
> Biswaroop
>
>
>
>
>
>
>
>
> The difference between sunrise and
> sunset lies in the freshness of your
> eyes.
> --Bisban
From jcpearso@ps.ucl.ac.uk Fri Apr 26 13:25:51 2002
From: jcpearso@ps.ucl.ac.uk (James Pearson)
Date: Fri, 26 Apr 2002 13:25:51 +0100
Subject: [hfs-user] To make a Readonly HFS Volume
In-Reply-To: Your message of Fri, 26 Apr 2002 16:47:54 +0530.
<008401c1ed14$06206640$1c0a0a0a@bisban>
Message-ID: <22410.1019823951@ourhome.freeserve.co.uk>
>I want to make a HFS volume readonly.
>I am setting the flag in mdb.drAtrb to
>
>mdb.drAtrb | = 0x4000 ( As said in Inside Macintosh)
>
>Bit Meaning
>15 Set if th volume is Locked by Software.
>
>After creating a Image of such a Volume.
> I am mounting it with a FreeWare application in Windows which can mount HFS
>volumes.
> But , I can still add files to that volume through this
> software and delete them too.
> That shows the volume is not Locked.
> So, anything else I should do to Volume parameters
> to make that Volume represent a ReadOnly one??
mkisofs (mkhybrid) makes a volume readonly using:
mdb.drAtrb |= HFS_ATRB_SLOCKED
where HFS_ATRB_SLOCKED is defined as (1 << 15) == 0x8000
Of course, this still assumes that whatever is mounting the volume honours the
readonly flag ...
James Pearson
From entwicklung@whengenibk.de Fri Apr 26 13:46:14 2002
From: entwicklung@whengenibk.de (Entwicklung)
Date: Fri, 26 Apr 2002 14:46:14 +0200
Subject: [hfs-user] To make a Readonly HFS Volume
References: <008401c1ed14$06206640$1c0a0a0a@bisban> <000801c1ed16$f54a1160$0401a7c0@modemserver> <009401c1ed1a$a3587320$1c0a0a0a@bisban>
Message-ID: <001e01c1ed20$60be1190$0401a7c0@modemserver>
Are you sure you've set drAtrb to 0 first before OR-ing 0x8000 with it ?
Or are you just setting mdb.drAtrb = 0x8000 instead of :
1) mdb.drAtrb = 0x0000;
2) mdb.drAtrb | = 0x8000 ;
Stt 2) without stt 1) might result in some unknown value getting written.
-Nandini
----- Original Message -----
From: "Biswaroop(External)"
To: "Entwicklung"
Sent: Friday, April 26, 2002 2:05 PM
Subject: Re: [hfs-user] To make a Readonly HFS Volume
> Hi Nandini,
> Thanks for a Quick Reply.
> But I did that too..but no success.
> regrds
> Biswaroop
> ----- Original Message -----
> From: "Entwicklung"
> To: "Biswaroop(External)"
> Cc:
> Sent: Friday, April 26, 2002 5:08 PM
> Subject: Re: [hfs-user] To make a Readonly HFS Volume
>
>
> > Wouldn't setting bit 15 give 0x8000 ??? numbering the 16 bits from 0..15
> > i.e.
> >
> > - Nandini
> >
> > ----- Original Message -----
> > From: "Biswaroop(External)"
> > To:
> > Sent: Friday, April 26, 2002 1:17 PM
> > Subject: [hfs-user] To make a Readonly HFS Volume
> >
> >
> > > Hi ,
> > >
> > > I want to make a HFS volume readonly.
> > > I am setting the flag in mdb.drAtrb to
> > >
> > > mdb.drAtrb | = 0x4000 ( As said in Inside Macintosh)
> > >
> > > Bit Meaning
> > > 15 Set if th volume is Locked by Software.
> > >
> > > After creating a Image of such a Volume.
> > > I am mounting it with a FreeWare application in Windows which can
mount
> > HFS
> > > volumes.
> > > But , I can still add files to that volume through this
> > > software and delete them too.
> > > That shows the volume is not Locked.
> > > So, anything else I should do to Volume parameters
> > > to make that Volume represent a ReadOnly one??
> > >
> > > Waiting for ur Inputs.
> > >
> > > Regards
> > > Biswaroop
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > > The difference between sunrise and
> > > sunset lies in the freshness of your
> > > eyes.
> > > --Bisban
From entwicklung@whengenibk.de Fri Apr 26 14:08:20 2002
From: entwicklung@whengenibk.de (Entwicklung)
Date: Fri, 26 Apr 2002 15:08:20 +0200
Subject: [hfs-user] Re: Desktop View
Message-ID: <004301c1ed23$71a79190$0401a7c0@modemserver>
This is a multi-part message in MIME format.
------=_NextPart_000_0040_01C1ED34.33985C70
Content-Type: text/plain;
charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Hi,
As Patrick had suggested - from the Apple technical notes I gathered =
that the structures I need to set the window settings of folders have =
the required form :
struct DInfo {
Rect frRect; /*folder's window rectangle*/
unsigned short frFlags; /*flags*/
Point frLocation; /*folder's location in window*/
short frView; /*folder's view*/
};
struct DXInfo {
Point frScroll; /*scroll position*/
long frOpenChain; /*directory ID chain of open =
folders*/
char frScript; /*script flag and code*/
char frXFlags; /*reserved*/
short frComment; /*comment ID*/
long frPutAway; /*directory ID*/
};
I want to set say my root folder's window size to a pretty large value =
so that as soon as I click on my CD-symbol a large window opens up =
displaying the contents of the CD.
Now Rect defines the size and location of a QuickDraw rectangle.
struct Rect {
short top;
short left;
short bottom;
short right;
};=20
top=20
The vertical coordinate of the upper-left point of the rectangle.=20
left=20
The horizontal coordinate of the upper-left point of the rectangle.=20
bottom=20
The vertical coordinate of the lower-right point of the rectangle.=20
right=20
The horizontal coordinate of the lower-right point of the rectangle.=20
I set top to 5, left to 5 bottom to 200 and right to 200...... but the =
default rectangle (a smaller sized one)
still continues to appear. What am I doing wrong out here ?.. sth wrong =
with the values ?=20
The rest of my finder flags are all set to 0 so the finder uses its =
default values. I'm only setting the creator and filetype of the files =
in addition to this.
Any tips would help a lot !
Regards,
Nandini
----- Original Message -----=20
From: Entwicklung=20
To: studentdev@lists.apple.com ; hfs-user@lists.mars.org ; =
darwin-development@lists.apple.com=20
Cc: Thomas Tempelmann=20
Sent: Thursday, April 25, 2002 8:06 AM
Subject: Desktop View
Hello,
I need some help.
I'd like to know what part of the HFS format is responsible for how =
icons on an external CD-volume appear on the desktop of Mac OS 9. The =
desktop database holds the icon info but where is info. like=20
Window-sizing on the Mac, no. of icons per row, spacing of icons etc. =
stored ? Is this stored on the hard-disk of the Mac or is there some way =
in which I can get this to be stored on my CD as well ? Is this part of =
the desktop database too ?
=20
The situation is as follows - when I insert my HFS-CD into my drive =
and click on the CD-symbol a window opens up displaying the icons for =
all the files present on the CD but they are not spaced properly and the =
view doesn't look all that good - Is there some way in which I can =
display these properly ? ..ie. say 'n' icons in one row etc ? Sometimes =
there are around 30 icons displayed for around 100 files on my CD... =
then a lot of empty space is displayed - which could mislead the user to =
think that no more files are present - and then the remaining 70 =
file-icons suddenly show up.
I presume this doesn't have to be stored on the external HFS-volume =
but rather has something to do with my Mac-OS settings... but I'm not =
too sure. I'd appreciate it if someone could tell me which part is =
responsible for such things ? I'm not creating a desktop DB at the =
moment but this looks really bad and I'd like to change it if I can i.e. =
if this can be overcome somehow without having a desktop database on my =
CD.
TIA,
Nandini
********** It's not easy to find happiness in ourselves and it's not =
possible to find it elsewhere ************
------=_NextPart_000_0040_01C1ED34.33985C70
Content-Type: text/html;
charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Hi,
As Patrick had suggested - from the =
Apple technical=20
notes I gathered that the structures I need to set the window settings =
of=20
folders have the required form :
struct DInfo =
{
=20
Rect &nb=
sp; =20
frRect; /*folder's window=20
rectangle*/
unsigned =
short =20
frFlags; =20
/*flags*/
=20
Point &n=
bsp;=20
frLocation; /*folder's location in=20
window*/
=20
short &n=
bsp;=20
frView; /*folder's=20
view*/
};
struct DXInfo {
=20
Point =20
frScroll; /*scroll=20
position*/
=20
long =20
frOpenChain; /*directory ID chain of open=20
folders*/
=20
char =20
frScript; /*script flag =
and=20
code*/
=20
char =20
frXFlags; =20
/*reserved*/
=20
short =20
frComment; /*comment=20
ID*/
=20
long =20
frPutAway; /*directory=20
ID*/
};
I want to set say my root folder's =
window size to a=20
pretty large value so that as soon as I click on my CD-symbol a large =
window=20
opens up displaying the contents of the CD.
Now Rect defines the size and location =
of a=20
QuickDraw rectangle.
struct Rect {
short&n=
bsp; top;
short &n=
bsp; left;
short b=
ottom;
short right;
=
};=20
- top=20
- The vertical coordinate of the upper-left point of the rectangle.=20
- left=20
- The horizontal coordinate of the upper-left point of the =
rectangle.=20
- bottom=20
- The vertical coordinate of the lower-right point of the rectangle. =
- right=20
- The horizontal coordinate of the lower-right point of the =
rectangle.=20
I set top to 5, left to 5 bottom to 200 =
and right=20
to 200...... but the default rectangle (a smaller sized =
one)
still continues to appear. What am I =
doing wrong=20
out here ?.. sth wrong with the values ?
The rest of my finder flags are all set =
to 0 so the=20
finder uses its default values. I'm only setting the creator and =
filetype of the=20
files in addition to this.
Any tips would help a lot =
!
Regards,
Nandini
----- Original Message -----
From:=20
Entwicklung
Sent: Thursday, April 25, 2002 =
8:06=20
AM
Subject: Desktop View
Hello,
I need some=20
help.
I'd like to know what part of the HFS =
format is=20
responsible for how icons on an external CD-volume appear on the =
desktop of=20
Mac OS 9. The desktop database holds the icon info but where is info. =
like=20
Window-sizing on the Mac, no. of =
icons per row,=20
spacing of icons etc. stored ? Is this stored on the hard-disk of the =
Mac or=20
is there some way in which I can get this to be stored on my CD =
as well ?=20
Is this part of the desktop database too ?
The situation is as follows - when I =
insert my=20
HFS-CD into my drive and click on the CD-symbol a window opens up =
displaying the icons for all the files present on the CD but they are =
not=20
spaced properly and the view doesn't look all that good - Is there =
some way in=20
which I can display these properly ? ..ie.=20
say 'n' icons in one row etc ? Sometimes there are around 30 =
icons=20
displayed for around 100 files on my CD... then a lot of empty space =
is=20
displayed - which could mislead the user to think that no more files =
are=20
present - and then the remaining 70 file-icons suddenly show =
up.
I presume this doesn't have to be =
stored on the=20
external HFS-volume but rather has something to do with my Mac-OS =
settings...=20
but I'm not too sure. I'd appreciate it if someone could tell me which =
part is=20
responsible for such things ? I'm not creating a desktop DB at the =
moment but=20
this looks really bad and I'd like to change it if I can i.e. if =
this can=20
be overcome somehow without having a desktop database on my=20
CD.
TIA,
Nandini
********** It's not easy to find =
happiness in=20
ourselves and it's not possible to find it elsewhere=20
************
------=_NextPart_000_0040_01C1ED34.33985C70--
From Biswaroop\(External\)" <000801c1ed16$f54a1160$0401a7c0@modemserver> <009401c1ed1a$a3587320$1c0a0a0a@bisban> <001e01c1ed20$60be1190$0401a7c0@modemserver>
Message-ID: <00ef01c1ed2a$240fa920$1c0a0a0a@bisban>
Hi Nandini,
Well if I make mdb.drAttrib = 0;
Then I will be nullifying the other volume conditions.
Therefore I am Oring it and I believe the code
which will check for the Readonly flag will have
this logic ..
if(mdb.drAttrib & HFS_READONLY)
{
//Means Volume is Readonly
}
where
# define HFS_READONLY (1<<15)
What do u say??
regs
Biswaroop
----- Original Message -----
From: "Entwicklung"
To: "Biswaroop(External)"
Cc:
Sent: Friday, April 26, 2002 6:16 PM
Subject: Re: [hfs-user] To make a Readonly HFS Volume
> Are you sure you've set drAtrb to 0 first before OR-ing 0x8000 with it ?
>
> Or are you just setting mdb.drAtrb = 0x8000 instead of :
>
> 1) mdb.drAtrb = 0x0000;
> 2) mdb.drAtrb | = 0x8000 ;
>
> Stt 2) without stt 1) might result in some unknown value getting written.
>
> -Nandini
>
>
> ----- Original Message -----
> From: "Biswaroop(External)"
> To: "Entwicklung"
> Sent: Friday, April 26, 2002 2:05 PM
> Subject: Re: [hfs-user] To make a Readonly HFS Volume
>
>
> > Hi Nandini,
> > Thanks for a Quick Reply.
> > But I did that too..but no success.
> > regrds
> > Biswaroop
> > ----- Original Message -----
> > From: "Entwicklung"
> > To: "Biswaroop(External)"
> > Cc:
> > Sent: Friday, April 26, 2002 5:08 PM
> > Subject: Re: [hfs-user] To make a Readonly HFS Volume
> >
> >
> > > Wouldn't setting bit 15 give 0x8000 ??? numbering the 16 bits from
0..15
> > > i.e.
> > >
> > > - Nandini
> > >
> > > ----- Original Message -----
> > > From: "Biswaroop(External)"
> > > To:
> > > Sent: Friday, April 26, 2002 1:17 PM
> > > Subject: [hfs-user] To make a Readonly HFS Volume
> > >
> > >
> > > > Hi ,
> > > >
> > > > I want to make a HFS volume readonly.
> > > > I am setting the flag in mdb.drAtrb to
> > > >
> > > > mdb.drAtrb | = 0x4000 ( As said in Inside Macintosh)
> > > >
> > > > Bit Meaning
> > > > 15 Set if th volume is Locked by Software.
> > > >
> > > > After creating a Image of such a Volume.
> > > > I am mounting it with a FreeWare application in Windows which can
> mount
> > > HFS
> > > > volumes.
> > > > But , I can still add files to that volume through this
> > > > software and delete them too.
> > > > That shows the volume is not Locked.
> > > > So, anything else I should do to Volume parameters
> > > > to make that Volume represent a ReadOnly one??
> > > >
> > > > Waiting for ur Inputs.
> > > >
> > > > Regards
> > > > Biswaroop
> > > >
> > > >
> > > >
> > > >
> > > >
> > > >
> > > >
> > > >
> > > > The difference between sunrise and
> > > > sunset lies in the freshness of your
> > > > eyes.
> > > > --Bisban
From entwicklung@whengenibk.de Fri Apr 26 15:44:10 2002
From: entwicklung@whengenibk.de (Entwicklung)
Date: Fri, 26 Apr 2002 16:44:10 +0200
Subject: [hfs-user] To make a Readonly HFS Volume
References: <008401c1ed14$06206640$1c0a0a0a@bisban> <000801c1ed16$f54a1160$0401a7c0@modemserver> <009401c1ed1a$a3587320$1c0a0a0a@bisban> <001e01c1ed20$60be1190$0401a7c0@modemserver> <00ef01c1ed2a$240fa920$1c0a0a0a@bisban>
Message-ID: <000601c1ed30$d790aac0$0401a7c0@modemserver>
> Well if I make mdb.drAttrib = 0;
> Then I will be nullifying the other volume conditions.
Not necessarily.... just check if mdb.drAttrib has been set to 0 right
before you OR it with your other conditions - not initializing your
variables correctly is obviously not a good choice... what kind of logic you
use is left to you..
- Nandini
> Therefore I am Oring it and I believe the code
> which will check for the Readonly flag will have
> this logic ..
> if(mdb.drAttrib & HFS_READONLY)
> {
> file://Means Volume is Readonly
> }
> where
> # define HFS_READONLY (1<<15)
>
> What do u say??
>
>
> ----- Original Message -----
> From: "Entwicklung"
> To: "Biswaroop(External)"
> Cc:
> Sent: Friday, April 26, 2002 6:16 PM
> Subject: Re: [hfs-user] To make a Readonly HFS Volume
>
>
> > Are you sure you've set drAtrb to 0 first before OR-ing 0x8000 with it ?
> >
> > Or are you just setting mdb.drAtrb = 0x8000 instead of :
> >
> > 1) mdb.drAtrb = 0x0000;
> > 2) mdb.drAtrb | = 0x8000 ;
> >
> > Stt 2) without stt 1) might result in some unknown value getting
written.
> >
> > -Nandini
> >
> >
> > ----- Original Message -----
> > From: "Biswaroop(External)"
> > To: "Entwicklung"
> > Sent: Friday, April 26, 2002 2:05 PM
> > Subject: Re: [hfs-user] To make a Readonly HFS Volume
> >
> >
> > > Hi Nandini,
> > > Thanks for a Quick Reply.
> > > But I did that too..but no success.
> > > regrds
> > > Biswaroop
> > > ----- Original Message -----
> > > From: "Entwicklung"
> > > To: "Biswaroop(External)"
> > > Cc:
> > > Sent: Friday, April 26, 2002 5:08 PM
> > > Subject: Re: [hfs-user] To make a Readonly HFS Volume
> > >
> > >
> > > > Wouldn't setting bit 15 give 0x8000 ??? numbering the 16 bits from
> 0..15
> > > > i.e.
> > > >
> > > > - Nandini
> > > >
> > > > ----- Original Message -----
> > > > From: "Biswaroop(External)"
> > > > To:
> > > > Sent: Friday, April 26, 2002 1:17 PM
> > > > Subject: [hfs-user] To make a Readonly HFS Volume
> > > >
> > > >
> > > > > Hi ,
> > > > >
> > > > > I want to make a HFS volume readonly.
> > > > > I am setting the flag in mdb.drAtrb to
> > > > >
> > > > > mdb.drAtrb | = 0x4000 ( As said in Inside Macintosh)
> > > > >
> > > > > Bit Meaning
> > > > > 15 Set if th volume is Locked by Software.
> > > > >
> > > > > After creating a Image of such a Volume.
> > > > > I am mounting it with a FreeWare application in Windows which can
> > mount
> > > > HFS
> > > > > volumes.
> > > > > But , I can still add files to that volume through this
> > > > > software and delete them too.
> > > > > That shows the volume is not Locked.
> > > > > So, anything else I should do to Volume parameters
> > > > > to make that Volume represent a ReadOnly one??
> > > > >
> > > > > Waiting for ur Inputs.
> > > > >
> > > > > Regards
> > > > > Biswaroop
> > > > >
> > > > >
> > > > >
> > > > >
> > > > >
> > > > >
> > > > >
> > > > >
> > > > > The difference between sunrise and
> > > > > sunset lies in the freshness of your
> > > > > eyes.
> > > > > --Bisban
From Biswaroop\(External\)"
Hi Everybody,
I have enquired a very queer problem.
What I did...
1. Created a Volume File and inserted some
Text documents in that volume.
2. I then wrote that Volume Image file on to a CD
using a mastering application which just dumps the
image on to the disc.
3. Took the CD and mounted it in Mac OS 9.2
The files were displayed but when I clicked it
for opening it I got a Error Mssg saying
"Simple Text" cannot open this Kind of File.
4. Next I mounted it in Mac OS X the new OS from
Mac.
Amazing enough It showed all the files and the
data correctly.
Inference:
The data is written correctly on to the Cd and it
is being recognized by Mac (MAC OS X).
Both the OS show the files properly and recognize
it as HFS formatted volume.
Point to note..
Since the text files were copied from a Windows volume in Binary mode no
CRLF conversions were
done.
But in Mac OS X it didnot show any wrong display
and everything was fine.
Thirdly when I wrote other types of files in the volume
eg. *.htm, *.pdf
They were shown in both the Mac OS's(9.2 and X)
but again the Text files couldnot be opened only in
Mac OS 9.2
Fourthly,
when I mount the Volume File created by my application
using a freeware"HFVExplorer" I can view all the
files and data (i.e. Text files are getting opened and
displayed).
From all the above experiments
I think my code is not the Culprit!!
And only "Text Files" are not getting opened.
Then where is the BUG??
Any ideas!
have a nice weekend.
Bye
Biswaroop
The difference between sunrise and
sunset lies in the freshness of your
eyes.
--Bisban
From pwd@apple.com Fri Apr 26 16:46:39 2002
From: pwd@apple.com (Patrick Dirks)
Date: Fri, 26 Apr 2002 08:46:39 -0700
Subject: [hfs-user] Re: Desktop View
In-Reply-To: <004301c1ed23$71a79190$0401a7c0@modemserver>
Message-ID:
--Apple-Mail-1-726610609
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
charset=ISO-8859-1;
format=flowed
If you're zeroing out the other FinderInfo fields I suspect your=20
settings are being ignored by the Finder because the "initited" flag=20
isn't set in the Finder flags. That's the Finder's que that this=20
information has never been set and should be initialized to some default=20=
values.
-Patrick.
On Friday, April 26, 2002, at 06:08 AM, Entwicklung wrote:
> Hi,
> =A0
> As Patrick had suggested - from the Apple technical notes I gathered=20=
> that the structures I need to set the window settings of folders have=20=
> the required form :
> =A0
> struct DInfo {
> =A0=A0=A0=A0=A0 Rect=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 =
frRect;=A0=A0=A0=A0=A0=A0=A0 /*folder's window rectangle*/
> =A0=A0=A0=A0=A0 unsigned short=A0=A0=A0 frFlags;=A0=A0=A0=A0=A0=A0 =
/*flags*/
> =A0=A0=A0=A0=A0 Point=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 =
frLocation;=A0=A0=A0 /*folder's location in window*/
> =A0=A0=A0=A0=A0 short=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 =
frView;=A0=A0=A0=A0=A0=A0=A0 /*folder's view*/
> };
>
> struct DXInfo {
> =A0=A0=A0=A0=A0 Point=A0=A0=A0=A0=A0=A0=A0=A0=A0 frScroll;=A0=A0=A0=A0=A0=
=A0=A0=A0 /*scroll position*/
> =A0=A0=A0=A0=A0 long=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 frOpenChain;=A0=A0=A0=
=A0=A0 /*directory ID chain of open=20
> folders*/
> =A0=A0=A0=A0=A0 char=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 frScript;=A0=A0=A0=A0=
=A0=A0=A0=A0 /*script flag and code*/
> =A0=A0=A0=A0=A0 char=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 frXFlags;=A0=A0=A0=A0=
=A0=A0=A0=A0 /*reserved*/
> =A0=A0=A0=A0=A0 short=A0=A0=A0=A0=A0=A0=A0=A0=A0 frComment;=A0=A0=A0=A0=A0=
=A0=A0 /*comment ID*/
> =A0=A0=A0=A0=A0 long=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 frPutAway;=A0=A0=A0=A0=
=A0=A0=A0 /*directory ID*/
> };
> =A0
> I want to set say my root folder's window size to a pretty large value=20=
> so that as soon as I click on my CD-symbol a large window opens=20
> up=A0displaying the contents of the CD.
> Now Rect defines the size and location of a QuickDraw rectangle.
>
> struct=A0Rect=A0{
> =A0=A0=A0=A0short=A0=A0=A0=A0top;
> =A0=A0=A0=A0short=A0=A0=A0=A0left;
> =A0=A0=A0=A0short=A0=A0=A0=A0bottom;
> =A0=A0=A0=A0short=A0=A0=A0=A0right;
> };
>
> top
> The vertical coordinate of the upper-left point of the rectangle.
> left
> The horizontal coordinate of the upper-left point of the rectangle.
> bottom
> The vertical coordinate of the lower-right point of the rectangle.
> right
> The horizontal coordinate of the lower-right point of the rectangle.
>
> I set top to 5, left to 5 bottom to 200 and right to 200...... but the=20=
> default rectangle (a smaller sized one)
> still continues to appear. What am I doing wrong out here ?.. sth =
wrong=20
> with the values ?
> =A0
> The rest of my finder flags are all set to 0 so the finder uses its=20
> default values. I'm only setting the creator and filetype of the files=20=
> in addition to this.
> =A0
> Any tips would help a lot !
> =A0
> Regards,
> Nandini
> =A0
>
> ----- Original Message -----
> From: Entwicklung
> To: studentdev@lists.apple.com ; hfs-user@lists.mars.org ;=20
> darwin-development@lists.apple.com
> Cc: Thomas Tempelmann
> Sent: Thursday, April 25, 2002 8:06 AM
> Subject: Desktop View
>
> Hello,
> =A0=A0=A0=A0 I need some help.
> I'd like to know what part of the HFS format is responsible for how=20
> icons on an external CD-volume appear on the desktop of Mac OS 9. The=20=
> desktop database holds the icon info but where is info. like
> Window-sizing on the Mac, no. of icons per row, spacing of icons etc.=20=
> stored ? Is this stored on the hard-disk of the Mac or is=A0there some=20=
> way in which I can get this to be stored on my CD as well ? Is this=20
> part of the desktop database too ?
> =A0
> The situation is as follows - when I insert my HFS-CD into my drive =
and=20
> click on the=A0CD-symbol a window opens up displaying the icons for =
all=20
> the files present on the CD but they are not spaced properly and the=20=
> view doesn't look all that good - Is there some way in which I can=20
> display these=A0properly ? ..ie. say=A0'n' icons in one row etc ? =
Sometimes=20
> there are around 30 icons displayed for around 100 files on my CD...=20=
> then a lot of empty space is displayed - which could mislead the user=20=
> to think that no more files are present - and then the remaining 70=20
> file-icons suddenly show up.
> =A0
> I presume this doesn't have to be stored on the external HFS-volume =
but=20
> rather has something to do with my Mac-OS settings... but I'm not too=20=
> sure. I'd appreciate it if someone could tell me which part is=20
> responsible for such things ? I'm not creating a desktop DB at the=20
> moment but this looks really bad and I'd like to change it if I can=20
> i.e. if this=A0can be overcome somehow without=A0having a desktop =
database=20
> on my CD.
> =A0
> TIA,
> Nandini
> =A0
> =A0
> =A0
> ********** It's not easy to find happiness in ourselves and it's not=20=
> possible to find it elsewhere ************
>
--Apple-Mail-1-726610609
Content-Transfer-Encoding: quoted-printable
Content-Type: text/enriched;
charset=ISO-8859-1
If you're zeroing out the other FinderInfo fields I suspect your
settings are being ignored by the Finder because the "initited" flag
isn't set in the Finder flags. That's the Finder's que that this
information has never been set and should be initialized to some
default values.
-Patrick.
On Friday, April 26, 2002, at 06:08 AM, Entwicklung wrote:
=
ArialHi,
=A0
ArialAs Patrick had suggested -
from the Apple technical notes I gathered that the structures I need
to set the window settings of folders have the required form =
:
=A0
Arialstruct DInfo {
=A0=A0=A0=A0=A0 Rect=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 =
frRect;=A0=A0=A0=A0=A0=A0=A0 /*folder's window rectangle*/
=A0=A0=A0=A0=A0 unsigned short=A0=A0=A0 frFlags;=A0=A0=A0=A0=A0=A0 =
/*flags*/
=A0=A0=A0=A0=A0 Point=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 frLocation;=A0=A0=
=A0 /*folder's location in window*/
=A0=A0=A0=A0=A0 short=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 frView;=A0=A0=A0=
=A0=A0=A0=A0 /*folder's view*/
};
struct DXInfo {
=A0=A0=A0=A0=A0 Point=A0=A0=A0=A0=A0=A0=A0=A0=A0 frScroll;=A0=A0=A0=A0=A0=A0=
=A0=A0 /*scroll position*/
=A0=A0=A0=A0=A0 long=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 frOpenChain;=A0=A0=A0=A0=
=A0 /*directory ID chain of open
folders*/
=A0=A0=A0=A0=A0 char=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 frScript;=A0=A0=A0=A0=A0=
=A0=A0=A0 /*script flag and code*/
=A0=A0=A0=A0=A0 char=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 frXFlags;=A0=A0=A0=A0=A0=
=A0=A0=A0 /*reserved*/
=A0=A0=A0=A0=A0 short=A0=A0=A0=A0=A0=A0=A0=A0=A0 frComment;=A0=A0=A0=A0=A0=
=A0=A0 /*comment ID*/
=A0=A0=A0=A0=A0 long=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 frPutAway;=A0=A0=A0=A0=A0=
=A0=A0 /*directory ID*/
};
=A0
ArialI want to set say my root
folder's window size to a pretty large value so that as soon as I
click on my CD-symbol a large window opens up=A0displaying the contents
of the CD.
ArialNow Rect defines the size and
location of a QuickDraw rectangle.
struct=A0Rect=A0{
=A0=A0=A0=A0short=A0=A0=A0=A0top;
=A0=A0=A0=A0short=A0=A0=A0=A0left;
=A0=A0=A0=A0short=A0=A0=A0=A0bottom;
=A0=A0=A0=A0short=A0=A0=A0=A0right;
};Arial
=
topArial<=
smaller>
The vertical coordinate of the upper-left point of the rectangle.
=
leftArial=
The horizontal coordinate of the upper-left point of the rectangle.
=
bottomArial
The vertical coordinate of the lower-right point of the rectangle.
=
rightArial
The horizontal coordinate of the lower-right point of the rectangle.
I set top to 5, left to 5 bottom to 200 and right to 200...... but the
default rectangle (a smaller sized one)
Arialstill continues to appear.
What am I doing wrong out here ?.. sth wrong with the values =
?
=A0
ArialThe rest of my finder flags
are all set to 0 so the finder uses its default values. I'm only
setting the creator and filetype of the files in addition to =
this.
=A0
ArialAny tips would help a lot =
!
=A0
ArialRegards,
ArialNandini
Arial=A0
----- Original Message -----
From:
=
1999,1999,FFFFEntwicklung
To:
=
1999,1999,FFFFstudentdev@lists.apple.com<=
/color>
; =
1999,1999,FFFFhfs-user@lists.mars.org
; =
1999,1999,FFFFdarwin-development@lists.ap=
ple.com
Cc: 1999,1999,FFFFThomas
Tempelmann
Sent: Thursday, April 25, 2002 8:06 AM
Subject: Desktop View
ArialHello,
Arial=A0=A0=A0=A0 I need some =
help.
ArialI'd like to know what part of
the HFS format is responsible for how icons on an external CD-volume
appear on the desktop of Mac OS 9. The desktop database holds the icon
info but where is info. like
ArialWindow-sizing on the Mac, no.
of icons per row, spacing of icons etc. stored ? Is this stored on the
hard-disk of the Mac or is=A0there some way in which I can get this to
be stored on my CD as well ? Is this part of the desktop database too =
?
=A0
ArialThe situation is as follows -
when I insert my HFS-CD into my drive and click on the=A0CD-symbol a
window opens up displaying the icons for all the files present on the
CD but they are not spaced properly and the view doesn't look all that
good - Is there some way in which I can display
=
these=A0Arialpr=
operly
? ..ie. say=A0'n' icons in one row etc ? Sometimes there are around 30
icons displayed for around 100 files on my CD... then a lot of empty
space is displayed - which could mislead the user to think that no
more files are present - and then the remaining 70 file-icons suddenly
show up.
=A0
ArialI presume this doesn't have
to be stored on the external HFS-volume but rather has something to do
with my Mac-OS settings... but I'm not too sure. I'd appreciate it if
someone could tell me which part is responsible for such things ? I'm
not creating a desktop DB at the moment but this looks really bad and
I'd like to change it if I can i.e. if this=A0can be overcome somehow
without=A0having a desktop database on my CD.
=A0
ArialTIA,
ArialNandini
=A0
=A0
=A0
Arial********** It's not easy to
find happiness in ourselves and it's not possible to find it elsewhere
************
=
--Apple-Mail-1-726610609--
From pwd@apple.com Fri Apr 26 16:52:41 2002
From: pwd@apple.com (Patrick Dirks)
Date: Fri, 26 Apr 2002 08:52:41 -0700
Subject: [hfs-user] MacOS9.2 and MAC OS X
In-Reply-To: <011201c1ed30$e97a3d00$1c0a0a0a@bisban>
Message-ID:
Hi,
Sounds like you're not setting the Finder information for the files; Mac
OS 9 uses the Finder Type and creator to find an application to open the
file. Looks like SimpleText also looks at the file and checks to see
whether the type is "TEXT".
Mac OS X recognizes file extensions in addition to the Finder
information (and its TextEdit app obviously doesn't check the Finder
Type in the Finder Info) so it has no problem just gong straight at the
data.
If you want to verify your data structures, I bet "BBEdit" will read it
without regard for the Finder info.
Hope that helps,
-Patrick.
On Friday, April 26, 2002, at 07:44 AM, Biswaroop(External) wrote:
> Hi Everybody,
>
> I have enquired a very queer problem.
> What I did...
> 1. Created a Volume File and inserted some
> Text documents in that volume.
> 2. I then wrote that Volume Image file on to a CD
> using a mastering application which just dumps the
> image on to the disc.
> 3. Took the CD and mounted it in Mac OS 9.2
> The files were displayed but when I clicked it
> for opening it I got a Error Mssg saying
> "Simple Text" cannot open this Kind of File.
> 4. Next I mounted it in Mac OS X the new OS from
> Mac.
> Amazing enough It showed all the files and the
> data correctly.
> Inference:
> The data is written correctly on to the Cd and it
> is being recognized by Mac (MAC OS X).
> Both the OS show the files properly and recognize
> it as HFS formatted volume.
>
> Point to note..
> Since the text files were copied from a Windows volume in Binary
> mode no
> CRLF conversions were
> done.
> But in Mac OS X it didnot show any wrong display
> and everything was fine.
>
> Thirdly when I wrote other types of files in the volume
> eg. *.htm, *.pdf
> They were shown in both the Mac OS's(9.2 and X)
> but again the Text files couldnot be opened only in
> Mac OS 9.2
>
> Fourthly,
> when I mount the Volume File created by my application
> using a freeware"HFVExplorer" I can view all the
> files and data (i.e. Text files are getting opened and
> displayed).
> From all the above experiments
> I think my code is not the Culprit!!
> And only "Text Files" are not getting opened.
> Then where is the BUG??
> Any ideas!
> have a nice weekend.
> Bye
> Biswaroop
>
>
>
>
>
>
>
>
>
> The difference between sunrise and
> sunset lies in the freshness of your
> eyes.
> --Bisban
From entwicklung@whengenibk.de Sun Apr 28 06:59:38 2002
From: entwicklung@whengenibk.de (Entwicklung)
Date: Sun, 28 Apr 2002 07:59:38 +0200
Subject: [hfs-user] MacOS9.2 and MAC OS X
References:
Message-ID: <008f01c1ee79$e234f720$0401a7c0@modemserver>
That's surprising - coz even in Mac OS 9 I haven't had any problems with
Simpletext documents. As long as a '.txt' extension is there it wasn't
necessary to set filetype and creator - but this seemed to work
only for text-files.. for .pdf for example I had to explicitly set filetype
and creator.
How is it it works fine for me on Mac OS 9 (for text files i.e.) and doesn't
work for Biswaroop on Mac OS 9.2 ?
Regards,
Nandini
----- Original Message -----
From: "Patrick Dirks"
To: "Biswaroop(External)"
Cc:
Sent: Friday, April 26, 2002 5:52 PM
Subject: Re: [hfs-user] MacOS9.2 and MAC OS X
> Hi,
>
> Sounds like you're not setting the Finder information for the files; Mac
> OS 9 uses the Finder Type and creator to find an application to open the
> file. Looks like SimpleText also looks at the file and checks to see
> whether the type is "TEXT".
>
> Mac OS X recognizes file extensions in addition to the Finder
> information (and its TextEdit app obviously doesn't check the Finder
> Type in the Finder Info) so it has no problem just gong straight at the
> data.
>
> If you want to verify your data structures, I bet "BBEdit" will read it
> without regard for the Finder info.
>
> Hope that helps,
> -Patrick.
>
> On Friday, April 26, 2002, at 07:44 AM, Biswaroop(External) wrote:
>
> > Hi Everybody,
> >
> > I have enquired a very queer problem.
> > What I did...
> > 1. Created a Volume File and inserted some
> > Text documents in that volume.
> > 2. I then wrote that Volume Image file on to a CD
> > using a mastering application which just dumps the
> > image on to the disc.
> > 3. Took the CD and mounted it in Mac OS 9.2
> > The files were displayed but when I clicked it
> > for opening it I got a Error Mssg saying
> > "Simple Text" cannot open this Kind of File.
> > 4. Next I mounted it in Mac OS X the new OS from
> > Mac.
> > Amazing enough It showed all the files and the
> > data correctly.
> > Inference:
> > The data is written correctly on to the Cd and it
> > is being recognized by Mac (MAC OS X).
> > Both the OS show the files properly and recognize
> > it as HFS formatted volume.
> >
> > Point to note..
> > Since the text files were copied from a Windows volume in Binary
> > mode no
> > CRLF conversions were
> > done.
> > But in Mac OS X it didnot show any wrong display
> > and everything was fine.
> >
> > Thirdly when I wrote other types of files in the volume
> > eg. *.htm, *.pdf
> > They were shown in both the Mac OS's(9.2 and X)
> > but again the Text files couldnot be opened only in
> > Mac OS 9.2
> >
> > Fourthly,
> > when I mount the Volume File created by my application
> > using a freeware"HFVExplorer" I can view all the
> > files and data (i.e. Text files are getting opened and
> > displayed).
> > From all the above experiments
> > I think my code is not the Culprit!!
> > And only "Text Files" are not getting opened.
> > Then where is the BUG??
> > Any ideas!
> > have a nice weekend.
> > Bye
> > Biswaroop
> >
> >
> >
> >
> >
> >
> >
> >
> >
> > The difference between sunrise and
> > sunset lies in the freshness of your
> > eyes.
> > --Bisban
>
From entwicklung@whengenibk.de Sun Apr 28 07:16:13 2002
From: entwicklung@whengenibk.de (Entwicklung)
Date: Sun, 28 Apr 2002 08:16:13 +0200
Subject: [hfs-user] Re: Desktop View
References:
Message-ID: <00ae01c1ee7c$333fd020$0401a7c0@modemserver>
Hi Patrick,
Thanks for replying !
I'm setting the field Finder flags to 0x0100 (kHasBeenInited) as you had
mentioned in your first email .i.e. I'm setting the userInfo.frFlags field
for my root folder to this value (I haven't set the Bundle bit). I'm setting
finderInfo.frXFlags to 0 - I think these are some extended flags so this
shouldn't matter anyway (?)
I wanted the first window (corresponding to the root folder) which opens up
to be larger in size say -
top - 5
left - 5
bottom - 200
right - 200
Am I setting sth incorrectly?
Regards,
Nandini
----- Original Message -----
From: "Patrick Dirks"
To: "Entwicklung"
Cc: ; ;
Sent: Friday, April 26, 2002 5:46 PM
Subject: Re: [hfs-user] Re: Desktop View
> If you're zeroing out the other FinderInfo fields I suspect your
> settings are being ignored by the Finder because the "initited" flag
> isn't set in the Finder flags. That's the Finder's que that this
> information has never been set and should be initialized to some default
> values.
>
> -Patrick.
>
> On Friday, April 26, 2002, at 06:08 AM, Entwicklung wrote:
>
> > Hi,
> >
> > As Patrick had suggested - from the Apple technical notes I gathered
> > that the structures I need to set the window settings of folders have
> > the required form :
> >
> > struct DInfo {
> > Rect frRect; /*folder's window rectangle*/
> > unsigned short frFlags; /*flags*/
> > Point frLocation; /*folder's location in window*/
> > short frView; /*folder's view*/
> > };
> >
> > struct DXInfo {
> > Point frScroll; /*scroll position*/
> > long frOpenChain; /*directory ID chain of open
> > folders*/
> > char frScript; /*script flag and code*/
> > char frXFlags; /*reserved*/
> > short frComment; /*comment ID*/
> > long frPutAway; /*directory ID*/
> > };
> >
> > I want to set say my root folder's window size to a pretty large value
> > so that as soon as I click on my CD-symbol a large window opens
> > up displaying the contents of the CD.
> > Now Rect defines the size and location of a QuickDraw rectangle.
> >
> > struct Rect {
> > short top;
> > short left;
> > short bottom;
> > short right;
> > };
> >
> > top
> > The vertical coordinate of the upper-left point of the rectangle.
> > left
> > The horizontal coordinate of the upper-left point of the rectangle.
> > bottom
> > The vertical coordinate of the lower-right point of the rectangle.
> > right
> > The horizontal coordinate of the lower-right point of the rectangle.
> >
> > I set top to 5, left to 5 bottom to 200 and right to 200...... but the
> > default rectangle (a smaller sized one)
> > still continues to appear. What am I doing wrong out here ?.. sth wrong
> > with the values ?
> >
> > The rest of my finder flags are all set to 0 so the finder uses its
> > default values. I'm only setting the creator and filetype of the files
> > in addition to this.
> >
> > Any tips would help a lot !
> >
> > Regards,
> > Nandini
> >
> >
> > ----- Original Message -----
> > From: Entwicklung
> > To: studentdev@lists.apple.com ; hfs-user@lists.mars.org ;
> > darwin-development@lists.apple.com
> > Cc: Thomas Tempelmann
> > Sent: Thursday, April 25, 2002 8:06 AM
> > Subject: Desktop View
> >
> > Hello,
> > I need some help.
> > I'd like to know what part of the HFS format is responsible for how
> > icons on an external CD-volume appear on the desktop of Mac OS 9. The
> > desktop database holds the icon info but where is info. like
> > Window-sizing on the Mac, no. of icons per row, spacing of icons etc.
> > stored ? Is this stored on the hard-disk of the Mac or is there some
> > way in which I can get this to be stored on my CD as well ? Is this
> > part of the desktop database too ?
> >
> > The situation is as follows - when I insert my HFS-CD into my drive and
> > click on the CD-symbol a window opens up displaying the icons for all
> > the files present on the CD but they are not spaced properly and the
> > view doesn't look all that good - Is there some way in which I can
> > display these properly ? ..ie. say 'n' icons in one row etc ? Sometimes
> > there are around 30 icons displayed for around 100 files on my CD...
> > then a lot of empty space is displayed - which could mislead the user
> > to think that no more files are present - and then the remaining 70
> > file-icons suddenly show up.
> >
> > I presume this doesn't have to be stored on the external HFS-volume but
> > rather has something to do with my Mac-OS settings... but I'm not too
> > sure. I'd appreciate it if someone could tell me which part is
> > responsible for such things ? I'm not creating a desktop DB at the
> > moment but this looks really bad and I'd like to change it if I can
> > i.e. if this can be overcome somehow without having a desktop database
> > on my CD.
> >
> > TIA,
> > Nandini
> >
> >
> >
> > ********** It's not easy to find happiness in ourselves and it's not
> > possible to find it elsewhere ************
> _______________________________________________
> studentdev mailing list | studentdev@lists.apple.com
> Help/Unsubscribe/Archives:
http://www.lists.apple.com/mailman/listinfo/studentdev
> Do not post admin requests to the list. They will be ignored.
From entwicklung@whengenibk.de Sun Apr 28 11:18:52 2002
From: entwicklung@whengenibk.de (Entwicklung)
Date: Sun, 28 Apr 2002 12:18:52 +0200
Subject: [hfs-user] Hidden files
Message-ID: <001201c1ee9e$2119ffc0$0401a7c0@modemserver>
This is a multi-part message in MIME format.
------=_NextPart_000_000F_01C1EEAE.DBE2AB30
Content-Type: text/plain;
charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
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 =
thought that was just for editing icons and the like. Can one get to see =
hidden system-files at all ?
What else is ResEdit used for normally - is this relevant to external =
HFS-readonly volumes ?
Would be grateful for any tips/suggestions.
Regards,
Nandini=20
********** It's not easy to find happiness in ourselves and it's not =
possible to find it elsewhere ************
------=_NextPart_000_000F_01C1EEAE.DBE2AB30
Content-Type: text/html;
charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
How does one get to see hidden files/ =
change the=20
attributes on Mac OS 9 ? Someone had written that this is possible using =
Apple's=20
ResEdit but I thought that was just for editing icons and the like. Can =
one get=20
to see hidden system-files at all ?
What else is ResEdit used for normally =
- is this=20
relevant to external HFS-readonly volumes ?
Would be grateful for any=20
tips/suggestions.
Regards,
Nandini
********** It's not easy to find =
happiness in=20
ourselves and it's not possible to find it elsewhere=20
************
------=_NextPart_000_000F_01C1EEAE.DBE2AB30--
From Vallens@Colorado.EDU Sun Apr 28 16:31:07 2002
From: Vallens@Colorado.EDU (Alex Vallens)
Date: Sun, 28 Apr 2002 09:31:07 -0600
Subject: [hfs-user] Re: Hidden files
References: <001201c1ee9e$2119ffc0$0401a7c0@modemserver>
Message-ID: <3CCC06C1.F334CAA3@Colorado.EDU>
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 thought
> 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 extent.
There is no use editing resource forks of files on a read-only disk, because,
obviously, the changes made cannot be saved.
Alex
From coolvibe@hackerheaven.org Sun Apr 28 17:21:37 2002
From: coolvibe@hackerheaven.org (Emiel Kollof)
Date: Sun, 28 Apr 2002 18:21:37 +0200
Subject: [hfs-user] Re: Hidden files
In-Reply-To: <001201c1ee9e$2119ffc0$0401a7c0@modemserver>
References: <001201c1ee9e$2119ffc0$0401a7c0@modemserver>
Message-ID: <200204281821.37594.coolvibe@hackerheaven.org>
Op zondag 28 april 2002 12:18, schreef Entwicklung:
> How does one get to see hidden files/ change the attributes on Mac OS 9 ?
[snip]
> Would be grateful for any tips/suggestions.
Open Terminal.app, cd /, ls -l
there ya go.. Oh you want to see them in the finder? Open finder, type
+~ and type the path you'd like to go. You can make hidden files by
naming a file with the UNIX convention that files that start with a dot (.)
are hidden. But that's just the UNIX way of marking files hidden. I think
what people mean with ResEdit is that you can set certain HFS flags that mark
it as 'hidden' as well.
Just my 2 Eurocents,
Emiel Kollof
--
What publishers are looking for these days isn't radical feminism.
It's corporate feminism -- a brand of feminism designed to sell books
and magazines, three-piece suits, airline tickets, Scotch, cigarettes
and, most important, corporate America's message, which runs: "Yes,
women were discriminated against in the past, but that unfortunate
mistake has been remedied; now every woman can attain wealth, prestige
and power by dint of individual rather than collective effort."
-- Susan Gordon
From pwd@apple.com Sun Apr 28 23:25:36 2002
From: pwd@apple.com (Patrick Dirks)
Date: Sun, 28 Apr 2002 15:25:36 -0700
Subject: [hfs-user] MacOS9.2 and MAC OS X
In-Reply-To: <008f01c1ee79$e234f720$0401a7c0@modemserver>
Message-ID:
I have no idea. As far as I know there's nothing in Mac OS 9 that looks
at the content of a file to see if perhaps it's a text file. Of course
it's possible different versions of SimpleText don't contain any check,
or that the check is just a change in what was selected for display in
StandardFile. Clearly something's different between your system and
Biswaroop's.
-Patrick.
On Saturday, April 27, 2002, at 10:59 PM, Entwicklung wrote:
> That's surprising - coz even in Mac OS 9 I haven't had any problems with
> Simpletext documents. As long as a '.txt' extension is there it wasn't
> necessary to set filetype and creator - but this seemed to work
> only for text-files.. for .pdf for example I had to explicitly set
> filetype
> and creator.
>
> How is it it works fine for me on Mac OS 9 (for text files i.e.) and
> doesn't
> work for Biswaroop on Mac OS 9.2 ?
>
> Regards,
> Nandini
>
>
> ----- Original Message -----
> From: "Patrick Dirks"
> To: "Biswaroop(External)"
> Cc:
> Sent: Friday, April 26, 2002 5:52 PM
> Subject: Re: [hfs-user] MacOS9.2 and MAC OS X
>
>
>> Hi,
>>
>> Sounds like you're not setting the Finder information for the files;
>> Mac
>> OS 9 uses the Finder Type and creator to find an application to open
>> the
>> file. Looks like SimpleText also looks at the file and checks to see
>> whether the type is "TEXT".
>>
>> Mac OS X recognizes file extensions in addition to the Finder
>> information (and its TextEdit app obviously doesn't check the Finder
>> Type in the Finder Info) so it has no problem just gong straight at the
>> data.
>>
>> If you want to verify your data structures, I bet "BBEdit" will read it
>> without regard for the Finder info.
>>
>> Hope that helps,
>> -Patrick.
>>
>> On Friday, April 26, 2002, at 07:44 AM, Biswaroop(External) wrote:
>>
>>> Hi Everybody,
>>>
>>> I have enquired a very queer problem.
>>> What I did...
>>> 1. Created a Volume File and inserted some
>>> Text documents in that volume.
>>> 2. I then wrote that Volume Image file on to a CD
>>> using a mastering application which just dumps the
>>> image on to the disc.
>>> 3. Took the CD and mounted it in Mac OS 9.2
>>> The files were displayed but when I clicked it
>>> for opening it I got a Error Mssg saying
>>> "Simple Text" cannot open this Kind of File.
>>> 4. Next I mounted it in Mac OS X the new OS from
>>> Mac.
>>> Amazing enough It showed all the files and the
>>> data correctly.
>>> Inference:
>>> The data is written correctly on to the Cd and it
>>> is being recognized by Mac (MAC OS X).
>>> Both the OS show the files properly and recognize
>>> it as HFS formatted volume.
>>>
>>> Point to note..
>>> Since the text files were copied from a Windows volume in Binary
>>> mode no
>>> CRLF conversions were
>>> done.
>>> But in Mac OS X it didnot show any wrong display
>>> and everything was fine.
>>>
>>> Thirdly when I wrote other types of files in the volume
>>> eg. *.htm, *.pdf
>>> They were shown in both the Mac OS's(9.2 and X)
>>> but again the Text files couldnot be opened only in
>>> Mac OS 9.2
>>>
>>> Fourthly,
>>> when I mount the Volume File created by my application
>>> using a freeware"HFVExplorer" I can view all the
>>> files and data (i.e. Text files are getting opened and
>>> displayed).
>>> From all the above experiments
>>> I think my code is not the Culprit!!
>>> And only "Text Files" are not getting opened.
>>> Then where is the BUG??
>>> Any ideas!
>>> have a nice weekend.
>>> Bye
>>> Biswaroop
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>> The difference between sunrise and
>>> sunset lies in the freshness of your
>>> eyes.
>>> --Bisban
>>
>
From pwd@apple.com Sun Apr 28 23:25:36 2002
From: pwd@apple.com (Patrick Dirks)
Date: Sun, 28 Apr 2002 15:25:36 -0700
Subject: [hfs-user] MacOS9.2 and MAC OS X
In-Reply-To: <008f01c1ee79$e234f720$0401a7c0@modemserver>
Message-ID:
I have no idea. As far as I know there's nothing in Mac OS 9 that looks
at the content of a file to see if perhaps it's a text file. Of course
it's possible different versions of SimpleText don't contain any check,
or that the check is just a change in what was selected for display in
StandardFile. Clearly something's different between your system and
Biswaroop's.
-Patrick.
On Saturday, April 27, 2002, at 10:59 PM, Entwicklung wrote:
> That's surprising - coz even in Mac OS 9 I haven't had any problems with
> Simpletext documents. As long as a '.txt' extension is there it wasn't
> necessary to set filetype and creator - but this seemed to work
> only for text-files.. for .pdf for example I had to explicitly set
> filetype
> and creator.
>
> How is it it works fine for me on Mac OS 9 (for text files i.e.) and
> doesn't
> work for Biswaroop on Mac OS 9.2 ?
>
> Regards,
> Nandini
>
>
> ----- Original Message -----
> From: "Patrick Dirks"
> To: "Biswaroop(External)"
> Cc:
> Sent: Friday, April 26, 2002 5:52 PM
> Subject: Re: [hfs-user] MacOS9.2 and MAC OS X
>
>
>> Hi,
>>
>> Sounds like you're not setting the Finder information for the files;
>> Mac
>> OS 9 uses the Finder Type and creator to find an application to open
>> the
>> file. Looks like SimpleText also looks at the file and checks to see
>> whether the type is "TEXT".
>>
>> Mac OS X recognizes file extensions in addition to the Finder
>> information (and its TextEdit app obviously doesn't check the Finder
>> Type in the Finder Info) so it has no problem just gong straight at the
>> data.
>>
>> If you want to verify your data structures, I bet "BBEdit" will read it
>> without regard for the Finder info.
>>
>> Hope that helps,
>> -Patrick.
>>
>> On Friday, April 26, 2002, at 07:44 AM, Biswaroop(External) wrote:
>>
>>> Hi Everybody,
>>>
>>> I have enquired a very queer problem.
>>> What I did...
>>> 1. Created a Volume File and inserted some
>>> Text documents in that volume.
>>> 2. I then wrote that Volume Image file on to a CD
>>> using a mastering application which just dumps the
>>> image on to the disc.
>>> 3. Took the CD and mounted it in Mac OS 9.2
>>> The files were displayed but when I clicked it
>>> for opening it I got a Error Mssg saying
>>> "Simple Text" cannot open this Kind of File.
>>> 4. Next I mounted it in Mac OS X the new OS from
>>> Mac.
>>> Amazing enough It showed all the files and the
>>> data correctly.
>>> Inference:
>>> The data is written correctly on to the Cd and it
>>> is being recognized by Mac (MAC OS X).
>>> Both the OS show the files properly and recognize
>>> it as HFS formatted volume.
>>>
>>> Point to note..
>>> Since the text files were copied from a Windows volume in Binary
>>> mode no
>>> CRLF conversions were
>>> done.
>>> But in Mac OS X it didnot show any wrong display
>>> and everything was fine.
>>>
>>> Thirdly when I wrote other types of files in the volume
>>> eg. *.htm, *.pdf
>>> They were shown in both the Mac OS's(9.2 and X)
>>> but again the Text files couldnot be opened only in
>>> Mac OS 9.2
>>>
>>> Fourthly,
>>> when I mount the Volume File created by my application
>>> using a freeware"HFVExplorer" I can view all the
>>> files and data (i.e. Text files are getting opened and
>>> displayed).
>>> From all the above experiments
>>> I think my code is not the Culprit!!
>>> And only "Text Files" are not getting opened.
>>> Then where is the BUG??
>>> Any ideas!
>>> have a nice weekend.
>>> Bye
>>> Biswaroop
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>> The difference between sunrise and
>>> sunset lies in the freshness of your
>>> eyes.
>>> --Bisban
>>
>
From pwd@apple.com Mon Apr 29 05:44:10 2002
From: pwd@apple.com (Patrick Dirks)
Date: Sun, 28 Apr 2002 21:44:10 -0700
Subject: [hfs-user] Re: Hidden files
In-Reply-To: <3CCC06C1.F334CAA3@Colorado.EDU>
Message-ID:
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
>> thought
>> 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
> extent.
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
tools.
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,
-Pat Dirks.
From Biswaroop\(External\)"
Hi,
When I create a volume of bigger size for eg. 640 MB
Now since allocation units is fixed at 65536.
Therefore
Bytes per allocation unit becomes
640 * 2 ^20 / 65536 = 10 * 2^10 (10K) (approx)
That means if i give even one allocation block
for each file i am physically giving him 10k space
even though file may be some 100 bytes which
results in space wastage.
I also believe there is no solution because each
file should have atleast one allocation block
and each file should start from a new allocation
block .
I am just wondering if I am right???
Or there is some alternative!!
Waitng for ur comments.
regards
Biswaroop
The difference between sunrise and
sunset lies in the freshness of your
eyes.
--Bisban
From entwicklung@whengenibk.de Tue Apr 30 15:14:48 2002
From: entwicklung@whengenibk.de (Entwicklung)
Date: Tue, 30 Apr 2002 16:14:48 +0200
Subject: [hfs-user] Problem of Allocation Block Size
References: <000901c1f036$454a9320$1c0a0a0a@bisban>
Message-ID: <000801c1f051$63971ef0$0401a7c0@modemserver>
Hi Biswaroop,
You're right - for larger images a larger allocation
block size is necessary (limitation of HFS). The only 'alternative' would be
to use HFS+ and a smaller allocation block size.
-Nandini
----- Original Message -----
From: "Biswaroop(External)"
To:
Sent: Tuesday, April 30, 2002 1:00 PM
Subject: [hfs-user] Problem of Allocation Block Size
> Hi,
>
> When I create a volume of bigger size for eg. 640 MB
>
> Now since allocation units is fixed at 65536.
> Therefore
> Bytes per allocation unit becomes
> 640 * 2 ^20 / 65536 = 10 * 2^10 (10K) (approx)
> That means if i give even one allocation block
> for each file i am physically giving him 10k space
> even though file may be some 100 bytes which
> results in space wastage.
> I also believe there is no solution because each
> file should have atleast one allocation block
> and each file should start from a new allocation
> block .
> I am just wondering if I am right???
> Or there is some alternative!!
> Waitng for ur comments.
> regards
> Biswaroop
>
>
> The difference between sunrise and
> sunset lies in the freshness of your
> eyes.
> --Bisban
>
From pwd@apple.com Tue Apr 30 18:27:45 2002
From: pwd@apple.com (Patrick Dirks)
Date: Tue, 30 Apr 2002 10:27:45 -0700
Subject: [hfs-user] Problem of Allocation Block Size
In-Reply-To: <000901c1f036$454a9320$1c0a0a0a@bisban>
Message-ID: <959BBB0A-5C5F-11D6-BDA6-0003930DF574@apple.com>
Hi Biswaroop,
You're right; HFS limits the number of allocation blocks to be somewhere
between 2^31 and 2^32 at best, which forces allocation block sizes to
get larger and larger as the disk size goes up. This problem, and the
resulting waste of space, was one of the factors that drove the
development of HFS+ which can work with much smaller allocation blocks
than HFS for a given volume size.
-Patrick.
On Tuesday, April 30, 2002, at 04:00 AM, Biswaroop(External) wrote:
> Hi,
>
> When I create a volume of bigger size for eg. 640 MB
>
> Now since allocation units is fixed at 65536.
> Therefore
> Bytes per allocation unit becomes
> 640 * 2 ^20 / 65536 = 10 * 2^10 (10K) (approx)
> That means if i give even one allocation block
> for each file i am physically giving him 10k space
> even though file may be some 100 bytes which
> results in space wastage.
> I also believe there is no solution because each
> file should have atleast one allocation block
> and each file should start from a new allocation
> block .
> I am just wondering if I am right???
> Or there is some alternative!!
> Waitng for ur comments.
> regards
> Biswaroop
>
>
> The difference between sunrise and
> sunset lies in the freshness of your
> eyes.
> --Bisban
>
From entwicklung@whengenibk.de Thu May 2 07:46:13 2002
From: entwicklung@whengenibk.de (Entwicklung)
Date: Thu, 2 May 2002 08:46:13 +0200
Subject: [hfs-user] HFS-Plus and Wrappers
Message-ID: <000e01c1f1a5$0e16fd10$0401a7c0@modemserver>
This is a multi-part message in MIME format.
------=_NextPart_000_000B_01C1F1B5.D0B45BA0
Content-Type: text/plain;
charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Hello Listers,
Recently there was a bit of discussion on =
HFS-Wrappers on the hfs-user mailing list and how it allows a computer =
with HFS (but no HFS Plus support) to start up or display a ReadMe to =
the user to improve the user-experience.
The tech. notes (TN 1150: HFS Plus Volume Format) says that the HFS =
wrapper volume contains five files in the root folder - a ReadMe, System =
and Finder, Desktop DB and Desktop DF.
I'm a third-party developer creating an HFS-Plus volume (non-bootable) =
interested in extending the functionality of my HFS-Plus volume to =
include a Wrapper as well. I want to know whether:
1) these 5 files are actually necessary or it would suffice if only the =
ReadMe is present ?
2) would this mean that the Desktop DB and DF files would be present =
twice (on an Apple-initialized volume) ? - once in the HFS-Wrapper and =
once in the HFS-Plus catalog ?
3) is there any documentation from Apple which describes how this ReadMe =
file is stored up in the Wrapper's catalog (I gathered it's not hidden) =
in order to function as expected ?... reverse-engineering
can be painful sometimes..
4) are the contents of the ReadMe file fixed or could I write anything I =
want into it ?
Would be glad of any tips/suggestions !
-Nandini
***Every day is a new beginning..a brand new start, to bring joy and =
fulfilment to the sad and weary heart***
------=_NextPart_000_000B_01C1F1B5.D0B45BA0
Content-Type: text/html;
charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Hello Listers,
&nbs=
p; =20
Recently there was a bit of discussion on HFS-Wrappers on the hfs-user =
mailing=20
list and how it allows a computer with HFS (but no HFS Plus support) to =
start up=20
or display a ReadMe to the user to improve the =
user-experience.
The tech. notes (TN 1150: HFS Plus =
Volume Format)=20
says that the HFS wrapper volume contains five files in the root folder =
- a=20
ReadMe, System and Finder, Desktop DB and Desktop DF.
I'm a third-party developer creating an =
HFS-Plus=20
volume (non-bootable) interested in extending the functionality of my =
HFS-Plus=20
volume to include a Wrapper as well. I want to know =
whether:
1) these 5 files are actually necessary or it would suffice if only the =
ReadMe is=20
present ?
2) would this mean that the Desktop DB =
and DF files=20
would be present twice (on an Apple-initialized volume) ? - once in the=20
HFS-Wrapper and once in the HFS-Plus catalog ?
3) is there any documentation from =
Apple which=20
describes how this ReadMe file is stored up in the Wrapper's catalog=20
(I gathered it's not hidden) in order =
to function=20
as expected ?... reverse-engineering
can be painful sometimes..
4) are the contents of the ReadMe file =
fixed or=20
could I write anything I want into it ?
Would be glad of any tips/suggestions=20
!
-Nandini
***Every day is a new beginning..a =
brand new start,=20
to bring joy and fulfilment to the sad and weary=20
heart***
------=_NextPart_000_000B_01C1F1B5.D0B45BA0--
From pwd@apple.com Thu May 2 08:13:21 2002
From: pwd@apple.com (Patrick Dirks)
Date: Thu, 2 May 2002 00:13:21 -0700
Subject: [hfs-user] HFS-Plus and Wrappers
In-Reply-To: <000e01c1f1a5$0e16fd10$0401a7c0@modemserver>
Message-ID: <15FFA71E-5D9C-11D6-A77E-0003930DF574@apple.com>
--Apple-Mail-1--933271002
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
charset=ISO-8859-1;
format=flowed
1. You'll probably need at least 3: the ReadMe (or whatever file you =
like to have shown) and the Desktop DB and Desktop DF. The latter two =
are there to make the Finder happy; if they're not present the Finder =
will try to create them and will end up creating them somewhere in the =
bowels of whatever system happens to be running because they can't be =
created on the read-only disk. The wrapper also has no space available, =
typically. Altogether much better to have a skeleton Desktop DB and =
Desktop DF there. You can copy them from any freshly initialized HFS =
floppy: the Desktop DB will have a few blocks of valid data in a small =
file, the Desktop DF file should be zero length in all likelihood.
I'm not entirely sure why the System and Finder files are there; they =
might be there to placate simple-minded software that checks for them =
when deciding whether the volume is potentially bootable. If your =
wrapped HFS+ volume is unbootable anyway, I bet you can get away without =
them.
2. Yes, there are two completely unrelated sets of Desktop DB and =
Desktop DF files. The ones in the wrapper are ordinarily ignored =
because it's the "wrapped" HFS+ volume that's actually mounted. The =
ones in the wrapper can be empty - their content is largely irrelevant.
3. The ReadMe file is stored as an ordinary file on a plain HFS volume. =
Nothing special (that's the whole point - it's there for the consumption =
of systems that only know about HFS).
4. You can not only write anything you like in the ReadMe file, you can =
call the file anything you want, have anything else you want besides =
(wanna throw in a QuickTime movie of yourself? No problem!). It's =
strictly cosmetic, solely for the benefit of the poor human who suddenly =
can't find the hard drive's contents on this system.
The most interesting part of the wrapper volume is the pointer to the =
HFS+ volume embedded. I believe the blocks used by the HFS+ volume are =
usually specified as used up by the "Bad block" file on the wrapper =
volume, so the wrapper volume looks like a large volume with a few =
files, no free space, and a ton of bad blocks.
Hope that helps,
-Pat Dirks.
On Wednesday, May 1, 2002, at 11:46 PM, Entwicklung wrote:
> Hello Listers,
> =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 Recently there =
was a bit of discussion on HFS-Wrappers on the hfs-user mailing list and =
how it allows a computer with HFS (but no HFS Plus support) to start up =
or display a ReadMe to the user to improve the user-experience.
> The tech. notes (TN 1150: HFS Plus Volume Format) says that the HFS =
wrapper volume contains five files in the root folder - a ReadMe, System =
and Finder, Desktop DB and Desktop DF.
> =A0
> I'm a third-party developer creating an HFS-Plus volume (non-bootable) =
interested in extending the functionality of my HFS-Plus volume to =
include a Wrapper as well. I want to know whether:
> =A0
> 1)=A0these 5 files=A0are actually necessary or it would suffice if =
only the ReadMe is present ?
> 2) would this mean that the Desktop DB and DF files would be present =
twice (on an Apple-initialized volume) ? - once in the HFS-Wrapper and =
once in the HFS-Plus catalog ?
> 3) is there any documentation from Apple which describes how this =
ReadMe file is stored up in the Wrapper's catalog (I gathered it's not =
hidden) in order to function as expected ?... reverse-engineering
> can be painful sometimes..
> 4) are the contents of the ReadMe file fixed or could I write anything =
I want into it ?
> =A0
> Would be glad of any tips/suggestions !
> -Nandini
> =A0
> =A0
> ***Every day is a new beginning..a brand new start, to bring joy and =
fulfilment to the sad and weary heart***
--Apple-Mail-1--933271002
Content-Transfer-Encoding: quoted-printable
Content-Type: text/enriched;
charset=ISO-8859-1
1. You'll probably need at least 3: the ReadMe (or whatever file you
like to have shown) and the Desktop DB and Desktop DF. The latter two
are there to make the Finder happy; if they're not present the Finder
will try to create them and will end up creating them somewhere in the
bowels of whatever system happens to be running because they can't be
created on the read-only disk. The wrapper also has no space
available, typically. Altogether much better to have a skeleton
Desktop DB and Desktop DF there. You can copy them from any freshly
initialized HFS floppy: the Desktop DB will have a few blocks of valid
data in a small file, the Desktop DF file should be zero length in all
likelihood.
I'm not entirely sure why the System and Finder files are there; they
might be there to placate simple-minded software that checks for them
when deciding whether the volume is potentially bootable. If your
wrapped HFS+ volume is unbootable anyway, I bet you can get away
without them.
2. Yes, there are two completely unrelated sets of Desktop DB and
Desktop DF files. The ones in the wrapper are ordinarily ignored
because it's the "wrapped" HFS+ volume that's actually mounted. The
ones in the wrapper can be empty - their content is largely irrelevant.
3. The ReadMe file is stored as an ordinary file on a plain HFS
volume. Nothing special (that's the whole point - it's there for the
consumption of systems that only know about HFS).
4. You can not only write anything you like in the ReadMe file, you
can call the file anything you want, have anything else you want
besides (wanna throw in a QuickTime movie of yourself? No problem!).=20
It's strictly cosmetic, solely for the benefit of the poor human who
suddenly can't find the hard drive's contents on this system.
The most interesting part of the wrapper volume is the pointer to the
HFS+ volume embedded. I believe the blocks used by the HFS+ volume
are usually specified as used up by the "Bad block" file on the
wrapper volume, so the wrapper volume looks like a large volume with a
few files, no free space, and a ton of bad blocks.
Hope that helps,
-Pat Dirks.
On Wednesday, May 1, 2002, at 11:46 PM, Entwicklung wrote:
ArialHello =
Listers,
Arial=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=
=A0=A0=A0=A0=A0=A0=A0 Recently
there was a bit of discussion on HFS-Wrappers on the hfs-user mailing
list and how it allows a computer with HFS (but no HFS Plus support)
to start up or display a ReadMe to the user to improve the
user-experience.
ArialThe tech. notes (TN 1150: HFS
Plus Volume Format) says that the HFS wrapper volume contains five
files in the root folder - a ReadMe, System and Finder, Desktop DB and
Desktop DF.
=A0
ArialI'm a third-party developer
creating an HFS-Plus volume (non-bootable) interested in extending the
functionality of my HFS-Plus volume to include a Wrapper as well. I
want to know whether:
=A0
Arial1)=A0these 5 files=A0are =
actually
necessary or it would suffice if only the ReadMe is present =
?
Arial2) would this mean that the
Desktop DB and DF files would be present twice (on an
Apple-initialized volume) ? - once in the HFS-Wrapper and once in the
HFS-Plus catalog ?
Arial3) is there any documentation
from Apple which describes how this ReadMe file is stored up in the
Wrapper's catalog (I gathered it's not hidden) in order to function as
expected ?... reverse-engineering
Arialcan be painful =
sometimes..
Arial4) are the contents of the
ReadMe file fixed or could I write anything I want into it =
?
=A0
ArialWould be glad of any
tips/suggestions !
Arial-Nandini
=A0
=A0
Arial***Every day is a new
beginning..a brand new start, to bring joy and fulfilment to the sad
and weary heart***
=
--Apple-Mail-1--933271002--
From entwicklung@whengenibk.de Thu May 2 08:13:07 2002
From: entwicklung@whengenibk.de (Entwicklung)
Date: Thu, 2 May 2002 09:13:07 +0200
Subject: [hfs-user] HFS-Plus and Wrappers
References: <15FFA71E-5D9C-11D6-A77E-0003930DF574@apple.com>
Message-ID: <000f01c1f1a8$d0547440$0401a7c0@modemserver>
This is a multi-part message in MIME format.
------=_NextPart_000_000C_01C1F1B9.92F50720
Content-Type: text/plain;
charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Thanks for the reply !
Regarding 'bad blocks' - I haven't really marked any 'bad blocks' until =
now and am not too sure I know how it is done... will have to read up on =
that. Any idea what happens if I don't mark the blocks of the embedded =
volume as 'bad blocks' but just mark them as allocated in the allocation =
bitmap of the HFS-Wrapper ?=20
Could this be a potential cause of any problems ?
TIA,
Nandini =20
***Every day is a new beginning..a brand new start, to bring joy and =
fulfilment to the sad and weary heart***
----- Original Message -----=20
From: Patrick Dirks=20
To: Entwicklung=20
Cc: darwin-development@lists.apple.com ; studentdev@lists.apple.com ; =
hfs-user@lists.mars.org=20
Sent: Thursday, May 02, 2002 9:13 AM
Subject: Re: [hfs-user] HFS-Plus and Wrappers
1. You'll probably need at least 3: the ReadMe (or whatever file you =
like to have shown) and the Desktop DB and Desktop DF. The latter two =
are there to make the Finder happy; if they're not present the Finder =
will try to create them and will end up creating them somewhere in the =
bowels of whatever system happens to be running because they can't be =
created on the read-only disk. The wrapper also has no space available, =
typically. Altogether much better to have a skeleton Desktop DB and =
Desktop DF there. You can copy them from any freshly initialized HFS =
floppy: the Desktop DB will have a few blocks of valid data in a small =
file, the Desktop DF file should be zero length in all likelihood.
I'm not entirely sure why the System and Finder files are there; they =
might be there to placate simple-minded software that checks for them =
when deciding whether the volume is potentially bootable. If your =
wrapped HFS+ volume is unbootable anyway, I bet you can get away without =
them.
2. Yes, there are two completely unrelated sets of Desktop DB and =
Desktop DF files. The ones in the wrapper are ordinarily ignored because =
it's the "wrapped" HFS+ volume that's actually mounted. The ones in the =
wrapper can be empty - their content is largely irrelevant.
3. The ReadMe file is stored as an ordinary file on a plain HFS =
volume. Nothing special (that's the whole point - it's there for the =
consumption of systems that only know about HFS).
4. You can not only write anything you like in the ReadMe file, you =
can call the file anything you want, have anything else you want besides =
(wanna throw in a QuickTime movie of yourself? No problem!). It's =
strictly cosmetic, solely for the benefit of the poor human who suddenly =
can't find the hard drive's contents on this system.
The most interesting part of the wrapper volume is the pointer to the =
HFS+ volume embedded. I believe the blocks used by the HFS+ volume are =
usually specified as used up by the "Bad block" file on the wrapper =
volume, so the wrapper volume looks like a large volume with a few =
files, no free space, and a ton of bad blocks.
Hope that helps,
-Pat Dirks.
On Wednesday, May 1, 2002, at 11:46 PM, Entwicklung wrote:
Hello Listers,
Recently there was a bit of discussion on =
HFS-Wrappers on the hfs-user mailing list and how it allows a computer =
with HFS (but no HFS Plus support) to start up or display a ReadMe to =
the user to improve the user-experience.
The tech. notes (TN 1150: HFS Plus Volume Format) says that the HFS =
wrapper volume contains five files in the root folder - a ReadMe, System =
and Finder, Desktop DB and Desktop DF.
=20
I'm a third-party developer creating an HFS-Plus volume =
(non-bootable) interested in extending the functionality of my HFS-Plus =
volume to include a Wrapper as well. I want to know whether:
=20
1) these 5 files are actually necessary or it would suffice if only =
the ReadMe is present ?
2) would this mean that the Desktop DB and DF files would be present =
twice (on an Apple-initialized volume) ? - once in the HFS-Wrapper and =
once in the HFS-Plus catalog ?
3) is there any documentation from Apple which describes how this =
ReadMe file is stored up in the Wrapper's catalog (I gathered it's not =
hidden) in order to function as expected ?... reverse-engineering
can be painful sometimes..
4) are the contents of the ReadMe file fixed or could I write =
anything I want into it ?
=20
Would be glad of any tips/suggestions !
-Nandini
=20
=20
***Every day is a new beginning..a brand new start, to bring joy and =
fulfilment to the sad and weary heart***
------=_NextPart_000_000C_01C1F1B9.92F50720
Content-Type: text/html;
charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Thanks for the reply !
Regarding 'bad blocks' - I haven't =
really marked=20
any 'bad blocks' until now and am not too sure I know how it is done... =
will=20
have to read up on that. Any idea what happens if I don't mark the =
blocks of the=20
embedded volume as 'bad blocks' but just mark them as allocated in =
the=20
allocation bitmap of the HFS-Wrapper ?
Could this be a potential cause of any =
problems=20
?
TIA,
Nandini
***Every day is a new beginning..a =
brand new start,=20
to bring joy and fulfilment to the sad and weary =
heart***
----- Original Message -----
From:=20
Patrick =
Dirks
Sent: Thursday, May 02, 2002 =
9:13=20
AM
Subject: Re: [hfs-user] =
HFS-Plus and=20
Wrappers
1. You'll probably need at least 3: the ReadMe (or =
whatever=20
file you like to have shown) and the Desktop DB and Desktop DF. The =
latter two=20
are there to make the Finder happy; if they're not present the Finder =
will try=20
to create them and will end up creating them somewhere in the bowels =
of=20
whatever system happens to be running because they can't be created on =
the=20
read-only disk. The wrapper also has no space available, typically. =
Altogether=20
much better to have a skeleton Desktop DB and Desktop DF there. You =
can copy=20
them from any freshly initialized HFS floppy: the Desktop DB will have =
a few=20
blocks of valid data in a small file, the Desktop DF file should be =
zero=20
length in all likelihood.
I'm not entirely sure why the System =
and=20
Finder files are there; they might be there to placate simple-minded =
software=20
that checks for them when deciding whether the volume is potentially =
bootable.=20
If your wrapped HFS+ volume is unbootable anyway, I bet you can get =
away=20
without them.
2. Yes, there are two completely unrelated sets =
of=20
Desktop DB and Desktop DF files. The ones in the wrapper are =
ordinarily=20
ignored because it's the "wrapped" HFS+ volume that's actually =
mounted. The=20
ones in the wrapper can be empty - their content is largely=20
irrelevant.
3. The ReadMe file is stored as an ordinary file on =
a plain=20
HFS volume. Nothing special (that's the whole point - it's there for =
the=20
consumption of systems that only know about HFS).
4. You can =
not only=20
write anything you like in the ReadMe file, you can call the file =
anything you=20
want, have anything else you want besides (wanna throw in a QuickTime =
movie of=20
yourself? No problem!). It's strictly cosmetic, solely for the benefit =
of the=20
poor human who suddenly can't find the hard drive's contents on this=20
system.
The most interesting part of the wrapper volume is the =
pointer=20
to the HFS+ volume embedded. I believe the blocks used by the HFS+ =
volume are=20
usually specified as used up by the "Bad block" file on the wrapper =
volume, so=20
the wrapper volume looks like a large volume with a few files, no free =
space,=20
and a ton of bad blocks.
Hope that helps,
-Pat =
Dirks.
On=20
Wednesday, May 1, 2002, at 11:46 PM, Entwicklung wrote:
Hello =
Listers,
&nb=
sp; =20
Recently there was a bit of discussion on HFS-Wrappers on the =
hfs-user=20
mailing list and how it allows a computer with HFS (but no HFS Plus =
support)=20
to start up or display a ReadMe to the user to improve the =
user-experience.
The=20
tech. notes (TN 1150: HFS Plus Volume Format) says that the HFS =
wrapper=20
volume contains five files in the root folder - a ReadMe, System and =
Finder,=20
Desktop DB and Desktop =
DF.
I'm=20
a third-party developer creating an HFS-Plus volume (non-bootable)=20
interested in extending the functionality of my HFS-Plus volume to =
include a=20
Wrapper as well. I want to know=20
whether:
1) these=20
5 files are actually necessary or it would suffice if only the =
ReadMe=20
is present ?
2) would=20
this mean that the Desktop DB and DF files would be present twice =
(on an=20
Apple-initialized volume) ? - once in the HFS-Wrapper and once in =
the=20
HFS-Plus catalog ?
3) is=20
there any documentation from Apple which describes how this ReadMe =
file is=20
stored up in the Wrapper's catalog (I gathered it's not hidden) in =
order to=20
function as expected ?... =
reverse-engineering
can=20
be painful =
sometimes..
4)=20
are the contents of the ReadMe file fixed or could I write anything =
I want=20
into it ?
Would=20
be glad of any tips/suggestions =
!
-Nandini
=
***Every=20
day is a new beginning..a brand new start, to bring joy and =
fulfilment to=20
the sad and weary=20
heart***
------=_NextPart_000_000C_01C1F1B9.92F50720--
From pwd@apple.com Thu May 2 08:29:57 2002
From: pwd@apple.com (Patrick Dirks)
Date: Thu, 2 May 2002 00:29:57 -0700
Subject: [hfs-user] HFS-Plus and Wrappers
In-Reply-To: <000f01c1f1a8$d0547440$0401a7c0@modemserver>
Message-ID: <678A85C8-5D9E-11D6-9CE0-0003930DF574@apple.com>
--Apple-Mail-1--932275202
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
charset=ISO-8859-1;
format=flowed
Only if you let some Disk Utility loose on it and it figures out those =
blocks aren't supposed to be marked in use because they're not claimed =
by any file...
Why don't you look at a freshly initialized HFS+ volume to see what all =
this is supposed to look like. See if you can account for every bit set =
on the volume - should be an interesting exercise!
-Pat.
On Thursday, May 2, 2002, at 12:13 AM, Entwicklung wrote:
> Thanks for the reply !
> Regarding 'bad blocks' - I haven't really marked any 'bad blocks' =
until now and am not too sure I know how it is done... will have to read =
up on that. Any idea what happens if I don't mark the blocks of the =
embedded volume as 'bad blocks' but just mark=A0them as allocated in the =
allocation bitmap of the HFS-Wrapper ?
> Could this be a potential cause of any problems ?
> =A0
> TIA,
> Nandini=A0
> =A0
> =A0
> ***Every day is a new beginning..a brand new start, to bring joy and =
fulfilment to the sad and weary heart***
>
> ----- Original Message -----
> From: Patrick Dirks
> To: Entwicklung
> Cc: darwin-development@lists.apple.com ; studentdev@lists.apple.com ; =
hfs-user@lists.mars.org
> Sent: Thursday, May 02, 2002 9:13 AM
> Subject: Re: [hfs-user] HFS-Plus and Wrappers
>
> 1. You'll probably need at least 3: the ReadMe (or whatever file you =
like to have shown) and the Desktop DB and Desktop DF. The latter two =
are there to make the Finder happy; if they're not present the Finder =
will try to create them and will end up creating them somewhere in the =
bowels of whatever system happens to be running because they can't be =
created on the read-only disk. The wrapper also has no space available, =
typically. Altogether much better to have a skeleton Desktop DB and =
Desktop DF there. You can copy them from any freshly initialized HFS =
floppy: the Desktop DB will have a few blocks of valid data in a small =
file, the Desktop DF file should be zero length in all likelihood.
>
> I'm not entirely sure why the System and Finder files are there; they =
might be there to placate simple-minded software that checks for them =
when deciding whether the volume is potentially bootable. If your =
wrapped HFS+ volume is unbootable anyway, I bet you can get away without =
them.
>
> 2. Yes, there are two completely unrelated sets of Desktop DB and =
Desktop DF files. The ones in the wrapper are ordinarily ignored because =
it's the "wrapped" HFS+ volume that's actually mounted. The ones in the =
wrapper can be empty - their content is largely irrelevant.
>
> 3. The ReadMe file is stored as an ordinary file on a plain HFS =
volume. Nothing special (that's the whole point - it's there for the =
consumption of systems that only know about HFS).
>
> 4. You can not only write anything you like in the ReadMe file, you =
can call the file anything you want, have anything else you want besides =
(wanna throw in a QuickTime movie of yourself? No problem!). It's =
strictly cosmetic, solely for the benefit of the poor human who suddenly =
can't find the hard drive's contents on this system.
>
> The most interesting part of the wrapper volume is the pointer to the =
HFS+ volume embedded. I believe the blocks used by the HFS+ volume are =
usually specified as used up by the "Bad block" file on the wrapper =
volume, so the wrapper volume looks like a large volume with a few =
files, no free space, and a ton of bad blocks.
>
> Hope that helps,
> -Pat Dirks.
>
> On Wednesday, May 1, 2002, at 11:46 PM, Entwicklung wrote:
>
> Hello Listers,
> =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 Recently there =
was a bit of discussion on HFS-Wrappers on the hfs-user mailing list and =
how it allows a computer with HFS (but no HFS Plus support) to start up =
or display a ReadMe to the user to improve the user-experience.
> The tech. notes (TN 1150: HFS Plus Volume Format) says that the HFS =
wrapper volume contains five files in the root folder - a ReadMe, System =
and Finder, Desktop DB and Desktop DF.
> =A0
> I'm a third-party developer creating an HFS-Plus volume (non-bootable) =
interested in extending the functionality of my HFS-Plus volume to =
include a Wrapper as well. I want to know whether:
> =A0
> 1)=A0these 5 files=A0are actually necessary or it would suffice if =
only the ReadMe is present ?
> 2) would this mean that the Desktop DB and DF files would be present =
twice (on an Apple-initialized volume) ? - once in the HFS-Wrapper and =
once in the HFS-Plus catalog ?
> 3) is there any documentation from Apple which describes how this =
ReadMe file is stored up in the Wrapper's catalog (I gathered it's not =
hidden) in order to function as expected ?... reverse-engineering
> can be painful sometimes..
> 4) are the contents of the ReadMe file fixed or could I write anything =
I want into it ?
> =A0
> Would be glad of any tips/suggestions !
> -Nandini
> =A0
> =A0
> ***Every day is a new beginning..a brand new start, to bring joy and =
fulfilment to the sad and weary heart***
>
--Apple-Mail-1--932275202
Content-Transfer-Encoding: quoted-printable
Content-Type: text/enriched;
charset=ISO-8859-1
Only if you let some Disk Utility loose on it and it figures out those
blocks aren't supposed to be marked in use because they're not claimed
by any file...
Why don't you look at a freshly initialized HFS+ volume to see what
all this is supposed to look like. See if you can account for every
bit set on the volume - should be an interesting exercise!
-Pat.
On Thursday, May 2, 2002, at 12:13 AM, Entwicklung wrote:
ArialThanks for the reply =
!
ArialRegarding 'bad blocks' - I
haven't really marked any 'bad blocks' until now and am not too sure I
know how it is done... will have to read up on that. Any idea what
happens if I don't mark the blocks of the embedded volume as 'bad
blocks' but just mark=A0them as allocated in the allocation bitmap of
the HFS-Wrapper ?
ArialCould this be a potential
cause of any problems ?
=A0
ArialTIA,
ArialNandini=A0=
=A0
=A0
Arial***Every day is a new
beginning..a brand new start, to bring joy and fulfilment to the sad
and weary heart***
----- Original Message -----
From:
1999,1999,FFFFPatrick =
Dirks
To:
=
1999,1999,FFFFEntwicklung
Cc:
=
1999,1999,FFFFdarwin-development@lists.ap=
ple.com
; =
1999,1999,FFFFstudentdev@lists.apple.com<=
/color>
; =
1999,1999,FFFFhfs-user@lists.mars.org
Sent: Thursday, May 02, 2002 9:13 AM
Subject: Re: [hfs-user] HFS-Plus and Wrappers
1. You'll probably need at least 3: the ReadMe (or whatever file you
like to have shown) and the Desktop DB and Desktop DF. The latter two
are there to make the Finder happy; if they're not present the Finder
will try to create them and will end up creating them somewhere in the
bowels of whatever system happens to be running because they can't be
created on the read-only disk. The wrapper also has no space
available, typically. Altogether much better to have a skeleton
Desktop DB and Desktop DF there. You can copy them from any freshly
initialized HFS floppy: the Desktop DB will have a few blocks of valid
data in a small file, the Desktop DF file should be zero length in all
likelihood.
I'm not entirely sure why the System and Finder files are there; they
might be there to placate simple-minded software that checks for them
when deciding whether the volume is potentially bootable. If your
wrapped HFS+ volume is unbootable anyway, I bet you can get away
without them.
2. Yes, there are two completely unrelated sets of Desktop DB and
Desktop DF files. The ones in the wrapper are ordinarily ignored
because it's the "wrapped" HFS+ volume that's actually mounted. The
ones in the wrapper can be empty - their content is largely irrelevant.
3. The ReadMe file is stored as an ordinary file on a plain HFS
volume. Nothing special (that's the whole point - it's there for the
consumption of systems that only know about HFS).
4. You can not only write anything you like in the ReadMe file, you
can call the file anything you want, have anything else you want
besides (wanna throw in a QuickTime movie of yourself? No problem!).
It's strictly cosmetic, solely for the benefit of the poor human who
suddenly can't find the hard drive's contents on this system.
The most interesting part of the wrapper volume is the pointer to the
HFS+ volume embedded. I believe the blocks used by the HFS+ volume are
usually specified as used up by the "Bad block" file on the wrapper
volume, so the wrapper volume looks like a large volume with a few
files, no free space, and a ton of bad blocks.
Hope that helps,
-Pat Dirks.
On Wednesday, May 1, 2002, at 11:46 PM, Entwicklung wrote:
Hello Listers,
=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 Recently there =
was a bit of discussion on
HFS-Wrappers on the hfs-user mailing list and how it allows a computer
with HFS (but no HFS Plus support) to start up or display a ReadMe to
the user to improve the user-experience.
The tech. notes (TN 1150: HFS Plus Volume Format) says that the HFS
wrapper volume contains five files in the root folder - a ReadMe,
System and Finder, Desktop DB and Desktop DF.
=A0
I'm a third-party developer creating an HFS-Plus volume (non-bootable)
interested in extending the functionality of my HFS-Plus volume to
include a Wrapper as well. I want to know whether:
=A0
1)=A0these 5 files=A0are actually necessary or it would suffice if only
the ReadMe is present ?
2) would this mean that the Desktop DB and DF files would be present
twice (on an Apple-initialized volume) ? - once in the HFS-Wrapper and
once in the HFS-Plus catalog ?
3) is there any documentation from Apple which describes how this
ReadMe file is stored up in the Wrapper's catalog (I gathered it's not
hidden) in order to function as expected ?... reverse-engineering
can be painful sometimes..
4) are the contents of the ReadMe file fixed or could I write anything
I want into it ?
=A0
Would be glad of any tips/suggestions !
-Nandini
=A0
=A0
***Every day is a new beginning..a brand new start, to bring joy and
fulfilment to the sad and weary heart***
=
--Apple-Mail-1--932275202--
From ssen@apple.com Thu May 2 08:55:19 2002
From: ssen@apple.com (Shantonu Sen)
Date: Thu, 2 May 2002 03:55:19 -0400
Subject: [hfs-user] Re: HFS-Plus and Wrappers
In-Reply-To: <000e01c1f1a5$0e16fd10$0401a7c0@modemserver>
Message-ID:
(I will probably get rejected from the lists I'm not on. If you are on multiple lists, please forward as appropriate)
On Thursday, May 2, 2002, at 02:46 AM, Entwicklung wrote:
> Recently there was a bit of discussion on HFS-Wrappers on
> the hfs-user mailing list and how it allows a computer with HFS (but no HFS
> Plus support) to start up or display a ReadMe to the user to improve the
> user-experience.
The HFS Wrapper is used to boot various Mac OS's on Old World machines. It serves no purpose on New World machines (except people with Dual G4's running Mac OS 7, probably ;-) ) More info below
> The tech. notes (TN 1150: HFS Plus Volume Format) says that the HFS wrapper
> volume contains five files in the root folder - a ReadMe, System and Finder,
> Desktop DB and Desktop DF.
Contains is probably a strong word. It happens to contain the above files. The System file is needed for Old World booting. The Finder is probably there to present a cohesive "System Folder" to old Mac OS's, in case they start freaking out because of a straw System file. For Mac OS X-created wrappers, the Finder file is 0 bytes (in data and resource forks) with the correct type/creator (FNDR/MACS).
> I'm a third-party developer creating an HFS-Plus volume (non-bootable)
> interested in extending the functionality of my HFS-Plus volume to include a
> Wrapper as well. I want to know whether:
Unfortunately, a wrapper alone will not get you close to bootability for Old World machines. For OS 9 (both old and new world), you will need to also set the boot blocks (the first 1KB of the filesystem). For Mac OS X, you would be set.
> 3) is there any documentation from Apple which describes how this ReadMe file
> is stored up in the Wrapper's catalog (I gathered it's not hidden) in order to
> function as expected ?... reverse-engineering
> can be painful sometimes..
It's just a file. You might learn a lot be reading the code for newfs_hfs in the diskdev_cmds project of Darwin. It shows how it creates the readme (the text is statically compiled into the newfs_hfs binary).
You might also be interested in checking out the bless-2 tag of the bless project from Dariwn CVS. In particular, look at bless/libbless/HFSWrapper/BLMountHFSWrapper.c and friends, which are basically abstractions that read the MDB, toggle the mdb->drEmbedSigWord to be kHFSSigWord, and writes it back out. Subsequent mounts of the volume will end up actually mounting the wrapper. Coming soon to an OS near you will be the capability of mounting the wrapper as part of mount_hfs, which will require new diskdev_cmds and xnu builds.
So, what is the System file doing there, and what does it do?
No Old World machine shipped with the ability to parse HFS+ volumes. However, Mac OS 8.6 (?) and later could boot from HFS+. How was that possible? Basically, the Mac OS ROM (which lived in actual ROM) would see the boot volume and find this HFS Wrapper thingy, which looked like an ordinary HFS volume. It would load the System file at that point, however, the System file in the wrapper is not a full OS System. It's just enough of a stub to add code to provide a bare-bones, read-only HFS+ implementation. This would go into the embedded HFS+ volume, read the HFS+ Volume Header and catalog, find the blessed folder, navigate to it, and load up the real System file. The real system file has the full-fledged read-write HFS+ volume code, at which point the OS can start it's thing. For Old World machines, if you want it to run OS 9, you need a wrapper, and unless you know better, use the apple-provided stub system file (licensing withstanding. I don't know those issues).
Does this apply to OS X/Darwin? To some extent yes. Apple Install CDs (Both commercial Mac OS X and the Darwin 1.4.1 distribution) have custom system files in the wrapper that patch Open Firmware to teach it how to boot Mac OS X and trigger a reboot. This is essentially how you can hold 'C' on an Old World machine and get it to boot a Mac OS X CD. The patches are similar (identical?) to the ones used to boot A/UX, and essentially tell Open Firmware to look in the partition map for disk block offsets containing executable code that should be used in the bootstrapping of the OS. After this code is loaded the booting process is pretty similar between old world and new world.
Do you need this System file to boot Mac OS X on Old World computers? strictly no, if they have already been patched. But if PRAM is zapped for some reason, you might want your volume to repatch OF.
Shantonu
From entwicklung@whengenibk.de Thu May 2 10:17:45 2002
From: entwicklung@whengenibk.de (Entwicklung)
Date: Thu, 2 May 2002 11:17:45 +0200
Subject: [hfs-user] Fw: HFS-Plus and Wrappers
Message-ID: <000201c1f1ba$7fb0f880$0401a7c0@modemserver>
----- Original Message -----
From: "Shantonu Sen"
To: "Entwicklung"
Cc: ; ;
Sent: Thursday, May 02, 2002 9:55 AM
Subject: Re: HFS-Plus and Wrappers
> (I will probably get rejected from the lists I'm not on. If you are on
multiple lists, please forward as appropriate)
>
> On Thursday, May 2, 2002, at 02:46 AM, Entwicklung wrote:
>
> > Recently there was a bit of discussion on
HFS-Wrappers on
> > the hfs-user mailing list and how it allows a computer with HFS (but no
HFS
> > Plus support) to start up or display a ReadMe to the user to improve the
> > user-experience.
>
> The HFS Wrapper is used to boot various Mac OS's on Old World machines. It
serves no purpose on New World machines (except people with Dual G4's
running Mac OS 7, probably ;-) ) More info below
>
> > The tech. notes (TN 1150: HFS Plus Volume Format) says that the HFS
wrapper
> > volume contains five files in the root folder - a ReadMe, System and
Finder,
> > Desktop DB and Desktop DF.
>
> Contains is probably a strong word. It happens to contain the above files.
The System file is needed for Old World booting. The Finder is probably
there to present a cohesive "System Folder" to old Mac OS's, in case they
start freaking out because of a straw System file. For Mac OS X-created
wrappers, the Finder file is 0 bytes (in data and resource forks) with the
correct type/creator (FNDR/MACS).
>
> > I'm a third-party developer creating an HFS-Plus volume (non-bootable)
> > interested in extending the functionality of my HFS-Plus volume to
include a
> > Wrapper as well. I want to know whether:
>
> Unfortunately, a wrapper alone will not get you close to bootability for
Old World machines. For OS 9 (both old and new world), you will need to also
set the boot blocks (the first 1KB of the filesystem). For Mac OS X, you
would be set.
>
> > 3) is there any documentation from Apple which describes how this ReadMe
file
> > is stored up in the Wrapper's catalog (I gathered it's not hidden) in
order to
> > function as expected ?... reverse-engineering
> > can be painful sometimes..
>
> It's just a file. You might learn a lot be reading the code for newfs_hfs
in the diskdev_cmds project of Darwin. It shows how it creates the readme
(the text is statically compiled into the newfs_hfs binary).
>
> You might also be interested in checking out the bless-2 tag of the bless
project from Dariwn CVS. In particular, look at
bless/libbless/HFSWrapper/BLMountHFSWrapper.c and friends, which are
basically abstractions that read the MDB, toggle the mdb->drEmbedSigWord to
be kHFSSigWord, and writes it back out. Subsequent mounts of the volume
will end up actually mounting the wrapper. Coming soon to an OS near you
will be the capability of mounting the wrapper as part of mount_hfs, which
will require new diskdev_cmds and xnu builds.
>
> So, what is the System file doing there, and what does it do?
>
> No Old World machine shipped with the ability to parse HFS+ volumes.
However, Mac OS 8.6 (?) and later could boot from HFS+. How was that
possible? Basically, the Mac OS ROM (which lived in actual ROM) would see
the boot volume and find this HFS Wrapper thingy, which looked like an
ordinary HFS volume. It would load the System file at that point, however,
the System file in the wrapper is not a full OS System. It's just enough of
a stub to add code to provide a bare-bones, read-only HFS+ implementation.
This would go into the embedded HFS+ volume, read the HFS+ Volume Header and
catalog, find the blessed folder, navigate to it, and load up the real
System file. The real system file has the full-fledged read-write HFS+
volume code, at which point the OS can start it's thing. For Old World
machines, if you want it to run OS 9, you need a wrapper, and unless you
know better, use the apple-provided stub system file (licensing
withstanding. I don't know those issues).
>
> Does this apply to OS X/Darwin? To some extent yes. Apple Install CDs
(Both commercial Mac OS X and the Darwin 1.4.1 distribution) have custom
system files in the wrapper that patch Open Firmware to teach it how to boot
Mac OS X and trigger a reboot. This is essentially how you can hold 'C' on
an Old World machine and get it to boot a Mac OS X CD. The patches are
similar (identical?) to the ones used to boot A/UX, and essentially tell
Open Firmware to look in the partition map for disk block offsets containing
executable code that should be used in the bootstrapping of the OS. After
this code is loaded the booting process is pretty similar between old world
and new world.
>
> Do you need this System file to boot Mac OS X on Old World computers?
strictly no, if they have already been patched. But if PRAM is zapped for
some reason, you might want your volume to repatch OF.
>
> Shantonu
> _______________________________________________
> darwin-development mailing list | darwin-development@lists.apple.com
> Help/Unsubscribe/Archives:
http://www.lists.apple.com/mailman/listinfo/darwin-development
> Do not post admin requests to the list. They will be ignored.
From entwicklung@whengenibk.de Thu May 2 10:49:52 2002
From: entwicklung@whengenibk.de (Entwicklung)
Date: Thu, 2 May 2002 11:49:52 +0200
Subject: [hfs-user] Re: HFS-Plus and Wrappers
References:
Message-ID: <001f01c1f1be$b5997d60$0401a7c0@modemserver>
> Are you programatically creating the filesystem yourself?
Yes.
>If so, Patrick and Shantonu gave you a good start worth of info.
Yes..Patrick and Shantonu : Thanks for the tips !
> But if so, why? Wouldn't it be easier just to run newfs_hfs?
Probably - but my project has to do with studying various FS-formats,
implementing them 'optimally' (however fuzzy the term may be :)) and
comparing them - that's why.
-Nandini
From Biswaroop\(External\)"
hi Everybody,
Well when I dump text files into a HFS volume and
mount it in a Mac OS9.2 and view them they show
some junk character for newline . I mean in Windows
newline is CRLF i.e. 2 characters. In Mac CR corresponds to newline and it
works also but the first
character in the next line starts with a junk.
Secondly if i mount the same volume in Mac OSx
there is no problem and it shows the data properly.
Why?? Since the same application is used to view
the files namely SimpleText.
Secondly what is the solution for this problem if
i mount a Hybrid Volume??
Since the data is only dumped once for the two filesystems and different
views are only shown namely
HFS and ISO9660.
Moreover if we view a ISO data CD and open
text files then there is no problem for the newline
character.
Any Explanations??
Waiting for them.
Regards
Biswaroop
God Only Created Earth.
We made two worlds out of it!
HEAVEN and HELL!!
From bierman@apple.com Thu May 2 10:44:43 2002
From: bierman@apple.com (Peter Bierman)
Date: Thu, 2 May 2002 02:44:43 -0700
Subject: [hfs-user] Re: HFS-Plus and Wrappers
In-Reply-To: <000e01c1f1a5$0e16fd10$0401a7c0@modemserver>
Message-ID:
At 8:46 AM +0200 5/2/02, Entwicklung wrote:
>I'm a third-party developer creating an HFS-Plus volume (non-bootable)
>interested in extending the functionality of my HFS-Plus volume to include a
>Wrapper as well. I want to know whether:
Are you programatically creating the filesystem yourself? If so, Patrick and Shantonu gave you a good start worth of info.
But if so, why? Wouldn't it be easier just to run newfs_hfs?
-pmb
From mday@apple.com Thu May 2 16:49:27 2002
From: mday@apple.com (Mark Day)
Date: Thu, 2 May 2002 08:49:27 -0700
Subject: [hfs-user] HFS-Plus and Wrappers
In-Reply-To: <000f01c1f1a8$d0547440$0401a7c0@modemserver>
Message-ID: <2F065170-5DE4-11D6-8BEE-00039354009A@apple.com>
On Thursday, May 2, 2002, at 12:13 AM, Entwicklung wrote:
> Regarding 'bad blocks' - I haven't really marked any 'bad blocks' until
> now and am not too sure I know how it is done... will have to read up
> on that.
You create one or more records in the Extents Overflow B-tree for file
ID 5 (kHFSBadBlockFileID), fork 0 (i.e. the data fork). Since there is
no entry for the bad blocks "file" in either the MDB or catalog, the
first record would have its startBlock set to 0 (i.e. offset of 0 blocks
into the "file"). If you need other discontiguous bad block extents,
you would create additional records.
> Any idea what happens if I don't mark the blocks of the embedded volume
> as 'bad blocks' but just mark them as allocated in the allocation
> bitmap of the HFS-Wrapper ?
> Could this be a potential cause of any problems ?
It might confuse older disk repair utilities that only see the wrapper,
or are trying to repair the wrapper as a plain HFS volume. For
read-only media, it probably isn't a serious problem. For writable
media, you would run the risk of having such a utility "repair" the
bitmap by unsetting the bits for the embedded volume, and potentially
overwriting part of the embedded volume when writing to the wrapper.
-Mark
From entwicklung@whengenibk.de Fri May 3 09:44:08 2002
From: entwicklung@whengenibk.de (Entwicklung)
Date: Fri, 3 May 2002 10:44:08 +0200
Subject: [hfs-user] Wrapper and Readme
Message-ID: <001401c1f27e$b2ec3470$0401a7c0@modemserver>
This is a multi-part message in MIME format.
------=_NextPart_000_0011_01C1F28F.749547F0
Content-Type: text/plain;
charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Hello Listers,
Thanks to the friendly feedback I got I managed to =
get started off with including an HFS-Wrapper in my code. It seems to =
work ok now but I'm not too sure... I only have access to an iMac with =
MacOS 9 - my HFS+ Volume gets displayed but how do I get to verify if =
the ReadMe I'm creating in the Wrapper is ok ? The volume is recognized =
as an HFS+ Volume (since the embedded volume seems to be getting mounted =
directly) and I can do a GetInfo on it. Do I necessarily need an older =
Mac which doesn't support HFS+ to get to see the ReadMe ?
I have one more question - Is it possible to have a Wrapper for =
HFS-volumes as well - embedding an HFS-volume within another HFS-Volume =
? I guess this wouldn't have any benefits as such but theoretically it =
should be possible, right ?
-Nandini
**************************************************
The really bad thing about software=20
is debugging it is a real nightmare=20
when you weed one bug out=20
then ten new ones will sprout=20
'til you get as mad as a march hare
*****************************************************=20
------=_NextPart_000_0011_01C1F28F.749547F0
Content-Type: text/html;
charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Hello Listers,
&nbs=
p; =20
Thanks to the friendly feedback I got I managed to get started off with=20
including an HFS-Wrapper in my code. It seems to work ok now but I'm not =
too=20
sure... I only have access to an iMac with MacOS 9 - my HFS+ Volume gets =
displayed but how do I get to verify if the ReadMe I'm creating in the =
Wrapper=20
is ok ? The volume is recognized as an HFS+ Volume (since the embedded =
volume=20
seems to be getting mounted directly) and I can do a GetInfo on it. Do I =
necessarily need an older Mac which doesn't support HFS+ to get to see =
the=20
ReadMe ?
I have one more question - Is it =
possible to have a=20
Wrapper for HFS-volumes as well - embedding an HFS-volume within =
another=20
HFS-Volume ? I guess this wouldn't have any benefits as such but=20
theoretically it should be possible, right ?
-Nandini
**************************************************
The really bad thing about software
is debugging it is a real =
nightmare=20
when you weed one bug out
then ten new ones will sprout
'til =
you get=20
as mad as a march hare
*****************************************************
=
------=_NextPart_000_0011_01C1F28F.749547F0--
From pwd@apple.com Fri May 3 10:52:31 2002
From: pwd@apple.com (Patrick Dirks)
Date: Fri, 3 May 2002 02:52:31 -0700
Subject: [hfs-user] Wrapper and Readme
In-Reply-To: <001401c1f27e$b2ec3470$0401a7c0@modemserver>
Message-ID: <7C9AFAF3-5E7B-11D6-82C8-003065A0E6DE@apple.com>
--Apple-Mail-1--837321086
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
charset=ISO-8859-1;
format=flowed
Hi,
It's probably pretty simple for testing purposes to remove the pointers =
to the "wrapped" HFS+ volume; the resulting disk image should then be =
just another HFS disk and you can use all the usual disk verification =
tools directly on it to see if there are any inconsistencies found. If =
all is well and you can double-click your "ReadMe" and see what you =
expect you can be reasonably confident that a user on a non-HFS+-savvy =
system would see exactly that, too.
Good luck,
-Pat Dirks.
On Friday, May 3, 2002, at 01:44 AM, Entwicklung wrote:
> Hello Listers,
> =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 Thanks =
to the friendly feedback I got I managed to get started off with =
including an HFS-Wrapper in my code. It seems to work ok now but I'm not =
too sure... I only have access to an iMac with MacOS 9 - my HFS+ Volume =
gets displayed but how do I get to verify if the ReadMe I'm creating in =
the Wrapper is ok ? The volume is recognized as an HFS+ Volume (since =
the embedded volume seems to be getting mounted directly) and I can do a =
GetInfo on it. Do I necessarily need an older Mac which doesn't support =
HFS+ to get to see the ReadMe ?
> =A0
> I have one more question - Is it possible to have a Wrapper for =
HFS-volumes as well=A0 - embedding an HFS-volume within another =
HFS-Volume ? I=A0guess this wouldn't have any benefits as such but =
theoretically it should be possible, right ?
> =A0
> -Nandini
> =A0
> =A0
> **************************************************
> =A0
>
> The really bad thing about software
> is debugging it is a real nightmare
> when you weed one bug out
> then ten new ones will sprout
> 'til you get as mad as a march hare
>
> =A0
>
> *****************************************************=A0
>
--Apple-Mail-1--837321086
Content-Transfer-Encoding: quoted-printable
Content-Type: text/enriched;
charset=ISO-8859-1
Hi,
It's probably pretty simple for testing purposes to remove the
pointers to the "wrapped" HFS+ volume; the resulting disk image should
then be just another HFS disk and you can use all the usual disk
verification tools directly on it to see if there are any
inconsistencies found. If all is well and you can double-click your
"ReadMe" and see what you expect you can be reasonably confident that
a user on a non-HFS+-savvy system would see exactly that, too.
Good luck,
-Pat Dirks.
On Friday, May 3, 2002, at 01:44 AM, Entwicklung wrote:
ArialHello =
Listers,
Arial=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=
=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 Thanks
to the friendly feedback I got I managed to get started off with
including an HFS-Wrapper in my code. It seems to work ok now but I'm
not too sure... I only have access to an iMac with MacOS 9 - my HFS+
Volume gets displayed but how do I get to verify if the ReadMe I'm
creating in the Wrapper is ok ? The volume is recognized as an HFS+
Volume (since the embedded volume seems to be getting mounted
directly) and I can do a GetInfo on it. Do I necessarily need an older
Mac which doesn't support HFS+ to get to see the ReadMe =
?
=A0
ArialI have one more question - Is
it possible to have a Wrapper for HFS-volumes as well=A0 - embedding an
HFS-volume within another HFS-Volume ? I=A0guess this wouldn't have any
benefits as such but theoretically it should be possible, right =
?
=A0
Arial-Nandini
=A0
=A0
=
Arial*********************************=
*****************
Arial=A0
The really bad thing about software
is debugging it is a real nightmare
when you weed one bug out
then ten new ones will sprout
'til you get as mad as a march hare
=A0
*****************************************************=A0
=
--Apple-Mail-1--837321086--
From mday@apple.com Fri May 3 15:56:11 2002
From: mday@apple.com (Mark Day)
Date: Fri, 3 May 2002 07:56:11 -0700
Subject: [hfs-user] Wrapper and Readme
In-Reply-To: <001401c1f27e$b2ec3470$0401a7c0@modemserver>
Message-ID:
On Friday, May 3, 2002, at 01:44 AM, Entwicklung wrote:
> Thanks to the friendly feedback I got I managed to get started off with including an HFS-Wrapper in my code. It seems to work ok now but I'm not too sure... I only have access to an iMac with MacOS 9 - my HFS+ Volume gets displayed but how do I get to verify if the ReadMe I'm creating in the Wrapper is ok ? The volume is recognized as an HFS+ Volume (since the embedded volume seems to be getting mounted directly) and I can do a GetInfo on it. Do I necessarily need an older Mac which doesn't support HFS+ to get to see the ReadMe ?
Probably the most convenient way is to change the drEmbedSigWord in the MDB. That will prevent the File Manager from recognizing it as an HFS Plus volume. It you don't want to burn another CD, then just make a disk image (use Disk Copy to make a read/write image so it will be a block-for-block copy) and use some file editor to change the signature. Then mount the image, and you should see the wrapper. If you're planning on verifying the disk using Disk First Aid or Disk Utility, you should also change the signature in the alternate MDB.
> I have one more question - Is it possible to have a Wrapper for HFS-volumes as well - embedding an HFS-volume within another HFS-Volume ? I guess this wouldn't have any benefits as such but theoretically it should be possible, right ?
Theoretically, the mechanism could be extended to include embedded things other than HFS Plus. That's the point of the drEmbedSigWord field in the MDB. However, there is no standard for any value other than 'H+', and no implementation that I know of would mount any other embedded volume.
The embedded extent is NOT treated like any old generic partition. Since HFS and HFS Plus volumes are so similar, a single filesystem plug-in handles both kinds of volumes (much like a single plug-in would handle FAT12, FAT16 and FAT32). It is inside that plug-in that the embedded volume is handled. It reads the block where the MDB should be. If it looks like an MDB, and the drEmbedSigWord is set to 'H+', and there is a Volume Header 1024 bytes from the start of the embedded extent, then the volume is recognized as (wrapped) HFS Plus.
-Mark
From entwicklung@whengenibk.de Fri May 3 16:55:11 2002
From: entwicklung@whengenibk.de (Entwicklung)
Date: Fri, 3 May 2002 17:55:11 +0200
Subject: [hfs-user] Wrapper and Readme
References: <7C9AFAF3-5E7B-11D6-82C8-003065A0E6DE@apple.com>
Message-ID: <002501c1f2bb$16bb62f0$0401a7c0@modemserver>
Hi,
I just tried it - and it works... Thanks for the tip!
Btw. Mark had written sth about Disk First Aid and the alternate volume
header - one problem I've been having right from the start is that Disk
First Aid is unable to read my CD and Norton Disk Doctor detects 'major
problems' on my CD. It seems as though this is due to the runout-blocks
being appended to the end of my image i.e. after the sector in which the
alternate volume header is present. This doesn't really disturb me too much
since the Mac mounts my CD's and reads them without a problem but I'd like
to know if there's sth I can do to overcome this.
-Nandini
----- Original Message -----
From: "Patrick Dirks"
To: "Entwicklung"
Cc: ; ;
Sent: Friday, May 03, 2002 11:52 AM
Subject: Re: [hfs-user] Wrapper and Readme
> Hi,
>
> It's probably pretty simple for testing purposes to remove the pointers to
the
> "wrapped" HFS+ volume; the resulting disk image should then be just
another
> HFS disk and you can use all the usual disk verification tools directly on
it
> to see if there are any inconsistencies found. If all is well and you can
> double-click your "ReadMe" and see what you expect you can be reasonably
> confident that a user on a non-HFS+-savvy system would see exactly that,
too.
>
> Good luck,
> -Pat Dirks.
>
> On Friday, May 3, 2002, at 01:44 AM, Entwicklung wrote:
>
> > Hello Listers,
> > Thanks to the friendly feedback I got I managed to
get
> started off with including an HFS-Wrapper in my code. It seems to work ok
now
> but I'm not too sure... I only have access to an iMac with MacOS 9 - my
HFS+
> Volume gets displayed but how do I get to verify if the ReadMe I'm
creating in
> the Wrapper is ok ? The volume is recognized as an HFS+ Volume (since the
> embedded volume seems to be getting mounted directly) and I can do a
GetInfo
> on it. Do I necessarily need an older Mac which doesn't support HFS+ to
get to
> see the ReadMe ?
> >
> > I have one more question - Is it possible to have a Wrapper for
HFS-volumes
> as well - embedding an HFS-volume within another HFS-Volume ? I guess
this
> wouldn't have any benefits as such but theoretically it should be
possible,
> right ?
> >
> > -Nandini
> >
> >
> > **************************************************
> >
> >
> > The really bad thing about software
> > is debugging it is a real nightmare
> > when you weed one bug out
> > then ten new ones will sprout
> > 'til you get as mad as a march hare
> >
> >
> >
> > *****************************************************
> _______________________________________________
> studentdev mailing list | studentdev@lists.apple.com
> Help/Unsubscribe/Archives:
http://www.lists.apple.com/mailman/listinfo/studentdev
> Do not post admin requests to the list. They will be ignored.
From mday@apple.com Fri May 3 17:48:52 2002
From: mday@apple.com (Mark Day)
Date: Fri, 3 May 2002 09:48:52 -0700
Subject: [hfs-user] Wrapper and Readme
In-Reply-To: <002501c1f2bb$16bb62f0$0401a7c0@modemserver>
Message-ID:
On Friday, May 3, 2002, at 08:55 AM, Entwicklung wrote:
> Btw. Mark had written sth about Disk First Aid and the alternate volume
> header - one problem I've been having right from the start is that Disk
> First Aid is unable to read my CD and Norton Disk Doctor detects 'major
> problems' on my CD. It seems as though this is due to the runout-blocks
> being appended to the end of my image i.e. after the sector in which the
> alternate volume header is present. This doesn't really disturb me too much
> since the Mac mounts my CD's and reads them without a problem but I'd like
> to know if there's sth I can do to overcome this.
Remember that the alternate MDB or alternate Volume Header starts 1024 bytes from the end of the volume. So, on a CD with 2048-byte physical sectors, it would start in the middle of the last physical sector. In the case of a wrapped HFS Plus volume, the alternate MDB is 1024 bytes from the end of the volume, and the alternate Volume Header is 1024 bytes from the end of the embedded part of the volume.
The last 512 bytes of the volume (and embedded volume) are reserved for uses outside the filesystem. Apple's manufacturing process uses the space for various things, without having to disturb the actual volume contents.
I don't know much about the low-level data organization on CDs, but I would think that the driver shouldn't include runout blocks as part of the data (i.e. part of the logical device or partition). Might you actually be writing data past the end of your volume?
If you're working with disk images, you could try truncating the image to 1024 bytes past the start of the alternate MDB (or alternate Volume Header for unwrapped HFS Plus volumes). But you still ought to figure out why there is extra data past the logical end of your volume (or why you aren't putting the alternate MDB/VH in the correct spot).
Disk First Aid tries to use the alternate MDB/VH to identify the volume and find the various structures. The idea is that if the first few blocks of the volume have been overwritten, Disk First Aid can find and fix the volume using the alternate structures, and write corrected information back out to the main MDB/VH. Current versions of DFA should try to find the main MDB/VH if it can't find any alternate. Norton Disk Doctor apparently only uses the main MDB/VH to find the volume's structures, and then later compares the alternate to the main copy.
-Mark
From entwicklung@whengenibk.de Fri May 3 17:56:21 2002
From: entwicklung@whengenibk.de (Entwicklung)
Date: Fri, 3 May 2002 18:56:21 +0200
Subject: [hfs-user] Wrapper and Readme
References:
Message-ID: <000801c1f2c3$7547aa60$0401a7c0@modemserver>
Hi,
> Remember that the alternate MDB or alternate Volume Header starts 1024
bytes from the end of the volume. So, on a CD with 2048-byte physical
sectors, it would start in the middle of the last physical sector. In the
case of a wrapped HFS Plus volume, the alternate MDB is 1024 bytes from the
end of the volume, and the alternate Volume Header is 1024 bytes from the
end of the embedded part of the volume.
Yes, that's the way it is in my implementation too...
> The last 512 bytes of the volume (and embedded volume) are reserved for
uses outside the filesystem. Apple's manufacturing process uses the space
for various things, without having to disturb the actual volume contents.
I've just set the last 512Bytes to zero - reserved.
> I don't know much about the low-level data organization on CDs, but I
would think that the driver shouldn't include runout blocks as part of the
data (i.e. part of the logical device or partition). Might you actually be
writing data past the end of your volume?
The runout blocks are just present after the data-part and get appended by
the driver responsible for writing out the data - starting off at the point
where the data ends. The logical part or partition ends 1024Bytes after the
start of the alternate volume header as you said.
> If you're working with disk images, you could try truncating the image to
1024 bytes past the start of the alternate MDB (or alternate Volume Header
for unwrapped HFS Plus volumes). But you still ought to figure out why
there is extra data past the logical end of your volume (or why you aren't
putting the alternate MDB/VH in the correct spot).
As mentioned - these extra blocks are not data but Disk First Aid apparently
mistakes them to be so since it starts checking from the end....Could it be
that I'm making a mistake in my allocation bitmap (in the volume header)?
.... if my HFS-volume has n sectors(2kB) including the 2kB blocks containing
the volume header and alternate volume header, with block size =512Bytes I
would have to account for (n-1)*4 if I'm marking all blocks as allocated,
right ? Or should it be (n-2)*4 ?
> Disk First Aid tries to use the alternate MDB/VH to identify the volume
and find the various structures. The idea is that if the first few blocks
of the volume have been overwritten, Disk First Aid can find and fix the
volume using the alternate structures, and write corrected information back
out to the main MDB/VH. Current versions of DFA should try to find the main
MDB/VH if it can't find any alternate.
Which are the versions which do this ?
TIA,
Nandini
From iosglpgc@teleline.es Sat May 4 15:05:23 2002
From: iosglpgc@teleline.es (Industrias O.S.G.)
Date: Sat, 4 May 2002 15:05:23 +0100
Subject: [hfs-user] MFS & HFS on-disk layout
Message-ID: <000401c1f374$bcbf15c0$0100a8c0@zeus>
Hi!
I need the docs that contains the MFS on-disk layout and the HFS on-disk
layout. They are no longer on the Apple web. Does someone have it?
Natasha Portillo
Industrias O.S.G.
Más allá del límite
Beyond the limits
begin 666 Natasha Portillo (Fax del trabajo).vcf
M0D5'24XZ5D-!4D0-"E9%4E-)3TXZ,BXQ#0I..E!O"!D96P@=')A8F%J;RD-"D]21SI)
M;F1U
> -Nandini
>
> ----- Original Message -----
> From: "Industrias O.S.G."
> To: "'Entwicklung'"
> Sent: Saturday, May 04, 2002 9:49 PM
> Subject: RE: [hfs-user] MFS & HFS on-disk layout
>
>
> > It was. No longer.
> >
> > Natasha Portillo
> > Industrias O.S.G.
> > Más allá del límite
> > Beyond the limits
> >
> >
> > > -----Original Message-----
> > > From: Entwicklung [mailto:entwicklung@whengenibk.de]
> > > Sent: Saturday, May 04, 2002 8:30 PM
> > > To: iosglpgc@teleline.es
> > > Cc: hfs-user@lists.mars.org
> > > Subject: Re: [hfs-user] MFS & HFS on-disk layout
> > >
> > >
> > > HFS should be available under Inside Macintosh-File Manager
> > > (Data Organization on Volumes)... downloadable as a .pdf file
> > > from the web.
> > >
> > > -Nandini
> > >
> > > ----- Original Message -----
> > > From: "Industrias O.S.G."
> > > To:
> > > Sent: Saturday, May 04, 2002 4:05 PM
> > > Subject: [hfs-user] MFS & HFS on-disk layout
> > >
> > >
> > > > Hi!
> > > >
> > > > I need the docs that contains the MFS on-disk layout and the HFS
> > > > on-disk layout. They are no longer on the Apple web. Does
> > > someone have
> > > > it?
> > > >
> > > > Natasha Portillo
> > > > Industrias O.S.G.
> > > > Más allá del límite
> > > > Beyond the limits
> > > >
> > > >
> > > >
> > >
> >
> >
> >
>
From entwicklung@whengenibk.de Mon May 6 10:38:00 2002
From: entwicklung@whengenibk.de (Entwicklung)
Date: Mon, 6 May 2002 11:38:00 +0200
Subject: [hfs-user] Executables..
Message-ID: <001801c1f4e1$b76dcd50$0401a7c0@modemserver>
This is a multi-part message in MIME format.
------=_NextPart_000_0015_01C1F4F2.79BBD360
Content-Type: text/plain;
charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Hello Listers,
I'd like to store some executable files (.exe) onto =
the HFS-CD I'm creating under Windows.
1) Is it possible to store up executables in a format recognizable on =
the Mac at all?
2) Would it be necessary to have a resource-fork for this purpose ?=20
3) What should I be taking into account ?
Any tips/suggestions are greatly appreciated.
-Nandini
*************************************************************************=
*********************************
Could you imagine the price of air if it were brought to you by another =
supplier ? - GOD
*************************************************************************=
**********************************
------=_NextPart_000_0015_01C1F4F2.79BBD360
Content-Type: text/html;
charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Hello Listers,
&nbs=
p; =20
I'd like to store some executable files (.exe) onto the HFS-CD I'm =
creating=20
under Windows.
1) Is it possible to store up =
executables in a=20
format recognizable on the Mac at all?
2) Would it be necessary to have a =
resource-fork=20
for this purpose ?
3) What should I be taking into account =
?
Any tips/suggestions are greatly=20
appreciated.
-Nandini
****************************************************************=
******************************************
Could you imagine the price of air if =
it were=20
brought to you by another supplier ? - =
GOD
****************************************************************=
*******************************************
------=_NextPart_000_0015_01C1F4F2.79BBD360--
From entwicklung@whengenibk.de Mon May 6 11:53:22 2002
From: entwicklung@whengenibk.de (Entwicklung)
Date: Mon, 6 May 2002 12:53:22 +0200
Subject: [hfs-user] hfsutils
Message-ID: <001001c1f4ec$4470d8f0$0401a7c0@modemserver>
This is a multi-part message in MIME format.
------=_NextPart_000_000B_01C1F4FD.016EDAF0
Content-Type: text/plain;
charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Hello,
I'd like to know if anyone who has used hfsutils in the past =
knows upto what allocation block size it supports for reading. I have an =
allocation block size of 64kB and I'm unable to mount my hfs-volume. It =
is slightly larger than 2GB in size. Images of size 32MB, 64MB upto =
512MB, 1GB and < 2GB seem to work fine.
I get the following error : Sorry, unable to mount volume. Read =
unallocated block (Input/Output error).
Does anybody know if hfsutils imposes a restriction on allocation block =
size or this error is due to some bug in my program ? What could =
possibly be causing this ?
Regards,
Nandini Hengen
------=_NextPart_000_000B_01C1F4FD.016EDAF0
Content-Type: text/html;
charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Hello,
I'd like=20
to know if anyone who has used hfsutils in the past knows upto what =
allocation=20
block size it supports for reading. I have an allocation block size =
of =20
64kB and I'm unable to mount my hfs-volume. It is slightly larger than =
2GB in=20
size. Images of size 32MB, 64MB upto 512MB, 1GB and < 2GB seem to =
work=20
fine.
I get the following error : Sorry, =
unable to mount=20
volume. Read unallocated block (Input/Output error).
Does anybody know if hfsutils imposes a =
restriction=20
on allocation block size or this error is due to some bug in my program =
? What=20
could possibly be causing this ?
Regards,
Nandini =
Hengen
------=_NextPart_000_000B_01C1F4FD.016EDAF0--
From gbeatty@cpc.gc.ca Mon May 6 20:33:16 2002
From: gbeatty@cpc.gc.ca (Gordon Beatty)
Date: Mon, 6 May 2002 15:33:16 -0400
Subject: [hfs-user] Unwrapped HFS+ volumes
Message-ID: <000501c1f534$df766f70$760aa8c0@cpc.gc.ca>
Hi all,
Since people have asked questions about wrapped HFS+ volumes, I was
reminded of a question I'd been meaning to ask. In general, by default,
HFS+ volumes are created with the HFS wrapper for compatibility and are
coded in the Partition Map with a type of 'Apple_HFS'. However, the
potential exists for HFS+ volumes to exist on their own without the wrapper
(especially where OS X is concerned -- or so I am led to believe).
My question is simply, would such an unwrapped volume be coded in the
Partition Map with the same type (Apple_HFS) or is there a type that exists
specifically for this case?
Gord Beatty
From mday@apple.com Mon May 6 20:41:26 2002
From: mday@apple.com (Mark Day)
Date: Mon, 6 May 2002 12:41:26 -0700
Subject: [hfs-user] Unwrapped HFS+ volumes
In-Reply-To: <000501c1f534$df766f70$760aa8c0@cpc.gc.ca>
Message-ID: <40C4E587-6129-11D6-BC83-00039354009A@apple.com>
On Monday, May 6, 2002, at 12:33 PM, Gordon Beatty wrote:
> My question is simply, would such an unwrapped volume be coded in the
> Partition Map with the same type (Apple_HFS) or is there a type that exists
> specifically for this case?
Pure HFS Plus volumes use partition type Apple_HFS, just like plain HFS or wrapped volumes.
-Mark
From rob@mars.org Tue May 7 02:20:36 2002
From: rob@mars.org (Rob Leslie)
Date: Mon, 6 May 2002 18:20:36 -0700
Subject: [hfs-user] hfsutils
In-Reply-To: <001001c1f4ec$4470d8f0$0401a7c0@modemserver>
Message-ID:
[I'm not subscribed to the darwin-development or studentdev lists; I'm not
sure this cross-posting is really appropriate.]
On Monday, May 6, 2002, at 03:53 AM, Entwicklung wrote:
> I'd like to know if anyone who has used hfsutils in the past
> knows upto what allocation block size it supports for reading. I have an
> allocation block size of 64kB and I'm unable to mount my hfs-volume. It
> is slightly larger than 2GB in size. Images of size 32MB, 64MB upto 512MB,
> 1GB and < 2GB seem to work fine.
>
> I get the following error : Sorry, unable to mount volume. Read
> unallocated block (Input/Output error).
>
> Does anybody know if hfsutils imposes a restriction on allocation block
> size or this error is due to some bug in my program ? What could possibly
> be causing this ?
It is not the allocation block size but the total volume size which is
likely to give hfsutils problems. Volumes >= 2GB require byte seek offsets
to be represented with at least 32 unsigned bits, a condition that
presents a problem on platforms where lseek() accepts a signed 32-bit
offset.
It's possible hfsutils could be changed to support volumes >= 2GB. Since
hfsutils reads and writes using physical block (512-byte) addresses,
perhaps even a simple cast in the call to lseek() would provide the
required support on platforms where off_t is larger than 32 bits.
--
Rob Leslie
rob@mars.org
From entwicklung@whengenibk.de Tue May 7 11:26:24 2002
From: entwicklung@whengenibk.de (Entwicklung)
Date: Tue, 7 May 2002 12:26:24 +0200
Subject: [hfs-user] hfsutils
References:
Message-ID: <006a01c1f5b1$a4dd5630$0401a7c0@modemserver>
Hello,
Thanks for replying !
> Rob Leslie wrote :
> It is not the allocation block size but the total volume size which is
> likely to give hfsutils problems. Volumes >= 2GB require byte seek offsets
> to be represented with at least 32 unsigned bits, a condition that
> presents a problem on platforms where lseek() accepts a signed 32-bit
> offset.
>
> It's possible hfsutils could be changed to support volumes >= 2GB. Since
> hfsutils reads and writes using physical block (512-byte) addresses,
> perhaps even a simple cast in the call to lseek() would provide the
> required support on platforms where off_t is larger than 32 bits.
Which platforms are these ? Im using hfsutils under Suse Linux 7.3 and am
also using
xhfs. Is a call to lseek() being made in a number of places ? I'd like your
advice as to how I should proceed. I had to internally change a number of
variables in my prog. from 'int' to 'unsigned long' to avoid an overflow. If
I could do this in the related files of fsutils and recompile or sth. to
make it work,
it would be great !
TIA,
Nandini
From entwicklung@whengenibk.de Tue May 7 15:10:41 2002
From: entwicklung@whengenibk.de (Entwicklung)
Date: Tue, 7 May 2002 16:10:41 +0200
Subject: [hfs-user] Icon for Readme...
References: <7C9AFAF3-5E7B-11D6-82C8-003065A0E6DE@apple.com>
Message-ID: <000c01c1f5d0$f9d4f390$0401a7c0@modemserver>
Hi,
1) What do I do if I want to store up my own customized icon for the ReadMe
file ?
2) Is this possible at all from another platform like Windows? (using the
resource fork of the file to dump my bitmap of the icon perhaps?)
3) Somebody said I would have to necessarily include sth. in the DTDB/DF
files which I've copied into my Wrapper from a freshly initialized
HFS-Volume on the Mac ? Is this true ? Can one even do without it ?
Where could I find relevant info about using Resource forks ? This has
really been a vague topic to me until now. My head is spinning with Bundle
bits and Finder flags right now...
Please do help.
-Nandini
----- Original Message -----
From: "Patrick Dirks"
To: "Entwicklung"
Cc: ; ;
Sent: Friday, May 03, 2002 11:52 AM
Subject: Re: [hfs-user] Wrapper and Readme
> Hi,
>
> It's probably pretty simple for testing purposes to remove the pointers to
the
> "wrapped" HFS+ volume; the resulting disk image should then be just
another
> HFS disk and you can use all the usual disk verification tools directly on
it
> to see if there are any inconsistencies found. If all is well and you can
> double-click your "ReadMe" and see what you expect you can be reasonably
> confident that a user on a non-HFS+-savvy system would see exactly that,
too.
>
> Good luck,
> -Pat Dirks.
>
> On Friday, May 3, 2002, at 01:44 AM, Entwicklung wrote:
>
> > Hello Listers,
> > Thanks to the friendly feedback I got I managed to
get
> started off with including an HFS-Wrapper in my code. It seems to work ok
now
> but I'm not too sure... I only have access to an iMac with MacOS 9 - my
HFS+
> Volume gets displayed but how do I get to verify if the ReadMe I'm
creating in
> the Wrapper is ok ? The volume is recognized as an HFS+ Volume (since the
> embedded volume seems to be getting mounted directly) and I can do a
GetInfo
> on it. Do I necessarily need an older Mac which doesn't support HFS+ to
get to
> see the ReadMe ?
> >
> > I have one more question - Is it possible to have a Wrapper for
HFS-volumes
> as well - embedding an HFS-volume within another HFS-Volume ? I guess
this
> wouldn't have any benefits as such but theoretically it should be
possible,
> right ?
> >
> > -Nandini
> >
> >
> > **************************************************
> >
> >
> > The really bad thing about software
> > is debugging it is a real nightmare
> > when you weed one bug out
> > then ten new ones will sprout
> > 'til you get as mad as a march hare
> >
> >
> >
> > *****************************************************
> _______________________________________________
> studentdev mailing list | studentdev@lists.apple.com
> Help/Unsubscribe/Archives:
http://www.lists.apple.com/mailman/listinfo/studentdev
> Do not post admin requests to the list. They will be ignored.
From rob@mars.org Tue May 7 21:49:08 2002
From: rob@mars.org (Rob Leslie)
Date: Tue, 7 May 2002 13:49:08 -0700
Subject: [hfs-user] hfsutils
In-Reply-To: <006a01c1f5b1$a4dd5630$0401a7c0@modemserver>
Message-ID:
On Tuesday, May 7, 2002, at 03:26 AM, Entwicklung wrote:
>> It's possible hfsutils could be changed to support volumes >= 2GB. Since
>> hfsutils reads and writes using physical block (512-byte) addresses,
>> perhaps even a simple cast in the call to lseek() would provide the
>> required support on platforms where off_t is larger than 32 bits.
>
> Which platforms are these ? Im using hfsutils under Suse Linux 7.3 and am
> also using xhfs. Is a call to lseek() being made in a number of places ?
> I'd like your advice as to how I should proceed. I had to internally
> change a number of variables in my prog. from 'int' to 'unsigned long' to
> avoid an overflow. If I could do this in the related files of fsutils
> and recompile or sth. to make it work, it would be great !
Well, I can't say for certain which platforms use which sizes, but for
example: on my Linux 2.2 system, sizeof(off_t) == 4, and on my Mac OS X 10.
1 system, sizeof(off_t) == 8.
The call to lseek() is localized to the file libhfs/os/unix.c, namely the
os_seek() routine. On platforms where sizeof(off_t) > 4, I think this
routine makes a mistake by not casting `offset' to off_t, since leaving it
as unsigned long may cause bits to be lost when it is left-shifted by
HFS_BLOCKSZ_BITS.
On platforms where sizeof(off_t) == 4, you'd have to find another method
to seek beyond 2GB, if one even exists. Linux offers _llseek(), for
example, but also keep in mind the ext2 filesystem does not support files
>= 2GB, so your image would have to be on a raw partition or another
filesystem or something.
--
Rob Leslie
rob@mars.org
From entwicklung@whengenibk.de Wed May 8 08:11:56 2002
From: entwicklung@whengenibk.de (Entwicklung)
Date: Wed, 8 May 2002 09:11:56 +0200
Subject: [hfs-user] Re: hfsutils
References:
Message-ID: <007e01c1f65f$d5be2960$0401a7c0@modemserver>
Hi,
Thanks for the reply.
The problem is that I don't have any medium(disk) for such large images. I'm
using Linux on an Intel PC and hfsutils since I can also specify a path to a
directory. Upto 650MB I was using a normal CD.
Manual mounting gives me the error 'not a block device' if I specify the
path to the image.
I also have no clue as to how I could write my image to a hard-disk perhaps
starting at physical block 0. Maybe after that a manual mount would be
possible.(?) But I guess that would probably be too tedious.
Any other tips as to what I could possibly do ? Is there some application on
the Mac which would allow me to mount the image-file as a volume ? ( maybe
if I send it across from my PC to the Mac per FTP ) - I presume the Mac
would see my file then as a regular file and not as an image of a volume
right ?
-Nandini
----- Original Message -----
From: "Don Brady"
To: "Entwicklung"
Sent: Monday, May 06, 2002 6:39 PM
Subject: Re: hfsutils
> What happens if you manually mount the disk?
> (eg mount -t hfs /dev/disk3 /Volumes/xyz)
>
> hfs.util calls /sbin/mount, which in turn calls /sbin/mount_hfs
>
> -Don
> Darwin File System Developer
>
>
> On Monday, May 6, 2002, at 03:53 AM, Entwicklung wrote:
>
> > Hello,
> > I'd like to know if anyone who has used hfsutils in the past
> > knows
> > upto what allocation block size it supports for reading. I have an
> > allocation
> > block size of 64kB and I'm unable to mount my hfs-volume. It is
> > slightly
> > larger than 2GB in size. Images of size 32MB, 64MB upto 512MB, 1GB
> > and < 2GB
> > seem to work fine.
> >
> > I get the following error : Sorry, unable to mount volume. Read
> > unallocated
> > block (Input/Output error).
> >
> > Does anybody know if hfsutils imposes a restriction on allocation block
> > size
> > or this error is due to some bug in my program ? What could possibly be
> > causing this ?
> >
> > Regards,
> > Nandini Hengen
> > _______________________________________________
> > darwin-development mailing list | darwin-development@lists.apple.com
> > Help/Unsubscribe/Archives:
> > http://www.lists.apple.com/mailman/listinfo/darwin-development
> > Do not post admin requests to the list. They will be ignored.
>
From Biswaroop\(External\)"
Hi everybody,
I want some help in finding a approximate value of the extents file.
Let me describe it...
I HAVE the following information
-->> Total no. of directories present in the volume
-->> Total no. of files with their full path and size in bytes.
-->> The total amount of space needed for the data of those files.
Problem faced :: Till now I used to find the total volume size first
since i knew the size of each file. And then as in the Linux implementation
they keep 1/128 th part of the Volume size as
the size of the Catalog File. The problem was when I used to select
some directories for eg. DDK folder whose total
size is around 58 MB and has around 4300 files in 300 directories.
The Catalog file size decided upon the volume
size would fill before all the entries were made and hence I would be
left wtih an incomplete filesystem.
I manipulated with different fiqures for the
Catalog file size but it was more a hit and trial method.
I know that Catalog File has information of the
whole directory structure of the volume in a B* tree format.
I also know at any given timeshot the B* tree
will be around 2/3 rds full.
I now know the size of the Catalog File depends
actually on the no. of File and Directory entries rather than the full
Volume size.
So, can anybody give me a simple formula ( may be
a good approximation) in trying to find out the Catalog File size needed
for a given volume when I have the information as
mentioned above.
Such that the file size may be bigger than
actually needed but not exceedingly big. In other words is there any way to
find out
the size from no. of Directory entries and file
entriee???
Waitng for help .
Bye
Biswaroop
God Created Earth.
We made two worlds out of it!
HEAVEN and HELL!!
From Biswaroop\(External\)"
Hi everybody,
I want some help in finding a approximate value of the extents file.
Let me describe it...
I HAVE the following information
-->> Total no. of directories present in the volume
-->> Total no. of files with their full path and size in bytes.
-->> The total amount of space needed for the data of those files.
Problem faced :: Till now I used to find the total volume size first
since i knew the size of each file. And then as in the Linux implementation
they keep 1/128 th part of the Volume size as the size of the Catalog File
The problem was when I used to select some directories for eg. DDK
folder whose total size is around 58 MB and has around 4300 files
in 300 directories. The Catalog file size decided upon the volume
size would fill before all the entries were made and hence I would be
left wtih an incomplete filesystem.I manipulated with different fiqures for
the
Catalog file size but it was more a hit and trial method.I know that Catalog
File
has information of the whole directory structure of the volume in a B* tree
format.
I also know at any given timeshot the B* tree will be around 2/3 rds full.
I now know the size of the Catalog File depends
actually on the no. of File and Directory entries rather than the full
Volume size.
So, can anybody give me a simple formula ( may be
a good approximation) in trying to find out the Catalog File size needed
for a given volume when I have the information as mentioned above.
Such that the file size may be bigger than
actually needed but not exceedingly big. In other words is there any way to
find out the size from no. of Directory entries and file
entriee???
Waitng for help .
Bye
Biswaroop
God Created Earth.
We made two worlds out of it!
HEAVEN and HELL!!
From entwicklung@whengenibk.de Wed Jun 19 16:08:45 2002
From: entwicklung@whengenibk.de (Entwicklung)
Date: Wed, 19 Jun 2002 17:08:45 +0200
Subject: [hfs-user] Displaying custom icon for a file
Message-ID: <3D109E7D.E53AE83C@whengenibk.de>
Hi,
How do I add an Icon family to a file and see the Icon being
displayed.
What I tried is as follows:
First add the icon family to a file using ResEdit
"Use Custom icon" in the properties of the file is set.
After saving the changes the Icon was still not displayed.
Please help me out.
Thanks In Advance
From entwicklung@whengenibk.de Thu Jun 20 09:35:04 2002
From: entwicklung@whengenibk.de (Entwicklung)
Date: Thu, 20 Jun 2002 10:35:04 +0200
Subject: [hfs-user] Adding to a Resource Fork of a File programmatically in Windows
Message-ID: <3D1193B8.70D1F473@whengenibk.de>
Hi,
I am working on a Project dealing with HFS and I need some help:
Is it possible to display a custom icon for a normal document(not an
application) - by writing the resource header, icon-list and resource
map in the file's resource fork. If possible how do I do it in
Windows(not in Mac)?
What is the structure of a resource fork? How do I programmatically
insert the resources into a file in Windows, so that the Icon resource
is visible when viewed in a Mac.
Entwicklung.
From entwicklung@whengenibk.de Fri Jun 21 10:30:22 2002
From: entwicklung@whengenibk.de (Entwicklung)
Date: Fri, 21 Jun 2002 11:30:22 +0200
Subject: [hfs-user] Structure of an ICN# Resource
Message-ID: <3D12F22E.7F112AFE@whengenibk.de>
Hi,
I am trying to write an Icon-Extractor.
Is there documentation available for the ICN# resource, regarding its
structure and other relevant details.I would like to know how I can
write Icon information into a file programmatically, once the Icon
information has been extracted.
TIA,
Entwicklung
From jude@smellycat.com Fri Jun 21 11:23:33 2002
From: jude@smellycat.com (Jude Giampaolo)
Date: Fri, 21 Jun 2002 06:23:33 -0400
Subject: [hfs-user] Structure of an ICN# Resource
In-Reply-To: <3D12F22E.7F112AFE@whengenibk.de>
Message-ID:
I think it's just raw bitmap data for the icons one after another:
/*----------------------------ICN# • Icon
List------------------------------------------*/
type 'ICN#' {
array {
hex string[128]; /* Icon
data */
};
};
On Friday, June 21, 2002, at 05:30 AM, Entwicklung wrote:
> Hi,
> I am trying to write an Icon-Extractor.
>
> Is there documentation available for the ICN# resource, regarding its
> structure and other relevant details.I would like to know how I can
> write Icon information into a file programmatically, once the Icon
> information has been extracted.
>
> TIA,
> Entwicklung
>
>
--
Jude Giampaolo
jude@smellycat.com http://www.smellycat.com/jude/
Woodpeckers: Nature's foley artists
From nathan_day@mac.com Fri Jun 21 16:16:17 2002
From: nathan_day@mac.com (Nathan Day)
Date: Sat, 22 Jun 2002 00:46:17 +0930
Subject: [hfs-user] Re: Structure of an ICN# Resource
In-Reply-To: <3D12F22E.7F112AFE@whengenibk.de>
Message-ID:
Yes there is documentation on this look for IconFamilies in carbon. the
ICN# is just the black and white icon resource there are other resources
as well. If you are trying to do this in Objective-C then don't waste
your time, it's been done already and the source code is freely
available,
http://homepage.mac.com/troy_stephens/software/objects/IconFamily/
On Friday, June 21, 2002, at 07:00 PM, Entwicklung wrote:
> Hi,
> I am trying to write an Icon-Extractor.
>
> Is there documentation available for the ICN# resource, regarding its
> structure and other relevant details.I would like to know how I can
> write Icon information into a file programmatically, once the Icon
> information has been extracted.
From entwicklung@whengenibk.de Mon Jun 24 16:31:05 2002
From: entwicklung@whengenibk.de (Entwicklung)
Date: Mon, 24 Jun 2002 17:31:05 +0200
Subject: [hfs-user] Writing to the Desktop Database
Message-ID: <3D173B39.79CC0DD0@whengenibk.de>
Hi,
I am working on a project where I am required to create a
Desktop Database.
I have more then 100 files of the same type for which I would
like to display the custom icon. I would like to know whether it is
possible to display the the custom icon for a file by putting the
relevant information in the Desktop Database. How can I set the creator,
type, kind and icon data for the custom icon files by writing into the
DTDB.
Is there a flag called "hasDTDB" present and is it system defined. If
so, where and how do we set it?
I am coding in the "Windows platform" so I would not be able to
user Mac routines. I am using a Mac to test whether my files are
displaying the proper icons later.
I would be thankful for any inputs in this regard.
Thank you,
Entwicklung.
From jcpearso@ps.ucl.ac.uk Thu Jun 27 15:10:01 2002
From: jcpearso@ps.ucl.ac.uk (James Pearson)
Date: Thu, 27 Jun 2002 15:10:01 +0100
Subject: [hfs-user] Format of '._' files on non-HFS(+) disks?
Message-ID: <168145.1025187001@ourhome.freeserve.co.uk>
Does anyone know where I can find out the layout of the files with names
starting with '._' that are created when an HFS/HFS+ file is copied to a
UFS, NFS etc file system?
Thanks
James Pearson
From mday@apple.com Thu Jun 27 16:35:58 2002
From: mday@apple.com (Mark Day)
Date: Thu, 27 Jun 2002 08:35:58 -0700
Subject: [hfs-user] Format of '._' files on non-HFS(+) disks?
In-Reply-To: <168145.1025187001@ourhome.freeserve.co.uk>
Message-ID: <93B63EBE-89E3-11D6-9D9D-00039354009A@apple.com>
On Thursday, June 27, 2002, at 07:10 AM, James Pearson wrote:
> Does anyone know where I can find out the layout of the files with
> names
> starting with '._' that are created when an HFS/HFS+ file is copied to
> a
> UFS, NFS etc file system?
It should be the second file of an AppleDouble pair. A quick search on
Google found the following link:
-Mark
From jcpearso@ps.ucl.ac.uk Thu Jun 27 17:53:09 2002
From: jcpearso@ps.ucl.ac.uk (James Pearson)
Date: Thu, 27 Jun 2002 17:53:09 +0100
Subject: [hfs-user] Format of '._' files on non-HFS(+) disks?
In-Reply-To: Your message of Thu, 27 Jun 2002 08:35:58 -0700.
<93B63EBE-89E3-11D6-9D9D-00039354009A@apple.com>
Message-ID: <167883.1025196789@ourhome.freeserve.co.uk>
>It should be the second file of an AppleDouble pair.
Thanks ... I should have guessed it would have been AppleDouble before
asking the question ...
However, do you know why '._' was chosen as the prefix for the
resource/finderinfo file when the specs for AppleDouble state '%' ...
James Pearson
From mday@apple.com Thu Jun 27 17:59:53 2002
From: mday@apple.com (Mark Day)
Date: Thu, 27 Jun 2002 09:59:53 -0700
Subject: [hfs-user] Format of '._' files on non-HFS(+) disks?
In-Reply-To: <167883.1025196789@ourhome.freeserve.co.uk>
Message-ID: <4D1D9D2C-89EF-11D6-9D9D-00039354009A@apple.com>
On Thursday, June 27, 2002, at 09:53 AM, James Pearson wrote:
> However, do you know why '._' was chosen as the prefix for the
> resource/finderinfo file when the specs for AppleDouble state '%' ...
The leading "." is the Unix convention for making a file invisible. I
think the underscore is to help avoid name collisions. If memory
serves, other Unix-based implementations that stored AppleDouble (eg.,
AU/X and maybe NetATalk) adopted the same naming convention.
-Mark
From iosglpgc@teleline.es Thu Jun 27 22:36:31 2002
From: iosglpgc@teleline.es (Natasha Portillo)
Date: Thu, 27 Jun 2002 22:36:31 +0100
Subject: [hfs-user] Format of '._' files on non-HFS(+) disks?
In-Reply-To: <167883.1025196789@ourhome.freeserve.co.uk>
Message-ID: <000401c21e22$c8208150$0100a8c0@zeus>
Starting dot makes it hidden... The % is used in UNIX for introducing
hexadecimal values of the character instead its graphic symbol (example,
%41 instead of A). I think these are the reasons :p
-----Mensaje original-----
De: hfs-user-admin@lists.mars.org [mailto:hfs-user-admin@lists.mars.org]
En nombre de James Pearson
Enviado el: jueves, 27 de junio de 2002 17:53
Para: Mark Day
CC: hfs-user@lists.mars.org
Asunto: Re: [hfs-user] Format of '._' files on non-HFS(+) disks?
>It should be the second file of an AppleDouble pair.
Thanks ... I should have guessed it would have been AppleDouble before
asking the question ...
However, do you know why '._' was chosen as the prefix for the
resource/finderinfo file when the specs for AppleDouble state '%' ...
James Pearson
From entwicklung@whengenibk.de Tue Jul 2 09:09:48 2002
From: entwicklung@whengenibk.de (Entwicklung)
Date: Tue, 02 Jul 2002 10:09:48 +0200
Subject: [hfs-user] Presence and Working of a Desktop Database
Message-ID: <3D215FCC.A78AD532@whengenibk.de>
Hi,
I am working on a project which requires me to understand the
internals of a Desktop Database on a CD. I have a few questions in this
regard. Any leads which can be provided would be of great help.
How does the Mac recognise the presence of a Desktop Database?
What are the required files, flags and structures that tell the Mac that
there is a Desktop Database on the HFS Volume CD it is reading. And what
are the routines used to write into these files, flags and structures.
Is there documentation on the structure and layout of the Desktop
Database(Both Desktop DB and DF files). Are there any other files which
are required by the Finder to read from the Desktop Database. Does the
Volume header have any information regarding the presence, size and
contents of a DTDB?
What happens when the user copies documents from the CD onto the hard
disk?
In case it is an application, the Finder updates the DTDB with the
information available from the resources. And we are able to see the
corresponding icon displayed properly. What happens incase of
user-defined files (not files which have custom icons) whose information
we store in the DTDB of the CD. When the file is viewed on the CD the
Finder displays the icon from the DTDB of the CD, but what happens when
the user copies it onto the hard disk? Is the information on the DTDB of
the CD for that file(not application) transferred to the hard disk of
the Mac.
From nand@gmx.de Mon Jul 22 08:55:50 2002
From: nand@gmx.de (nand@gmx.de)
Date: Mon, 22 Jul 2002 09:55:50 +0200 (MEST)
Subject: [hfs-user] Case-insensitive sort...
Message-ID: <7278.1027324550@www25.gmx.net>
Hello,
Both the HFS specs and the HFS+ technical notes say that the keys
of the records in the Catalog B-Tree have to be sorted in a case insensitive
fashion. The names are however in MacRoman and Unicode encoding respectively.
I stumbled across a case where I had underscores '_' in my filenames and the
Finder gave up on certain files on my HFS+ volume though the same sort
techniques worked fine for HFS.
It took me some time and quite a bit of trial and error to figure out that a
toupper(..) works fine for HFS but not for HFS+..... using a tolower(..)
instead solved the problem for Unicode... what's the reason ?... Is
'case-insensitive' sorting for MacRoman in some way different from case-insensitive
sorting for Unicode ??? Ultimately the same codes are used except for the fact
that we have a 2-Byte character representation, right ?
Any tips are greatly appreciated !
Regards,
Nandini
--
GMX - Die Kommunikationsplattform im Internet.
http://www.gmx.net
From m.siennicki@cloos.pl Tue Aug 20 23:27:50 2002
From: m.siennicki@cloos.pl (m.siennicki@cloos.pl)
Date: Wed, 21 Aug 2002 00:27:50 +0200
Subject: [hfs-user] Problems with MacBinaries
Message-ID: <20020821002750.A4049@mimi.domek.foo>
Hi,
First, I have to say that I'm Mac newbie --- I'm just playing
with an old 7300 for 2 days. For two days i'm trying to copy one
file (MacOS upgrade) into Mac's disk, and I cannot do it.
I downloaded the file into my PC, I attached Mac's disk into
mine PC SCSI bus and I try, and try, and try, ...
hmount works,
hdir, hcd works too, hcopy Mac disk -> e2fs works. But I cannot
copy any *.bin file into Mac disk.
When I try to copy files downloaded from apple.com, I see message:
hcopy: "THERE IS SOME .bin FILENAME": unknown, unsupported, or corrupt MacBinary file (Invalid argument)
When I try the other way, for example:
$ hcopy ":FreeHand 5.0.1" .
I get the .bin file, but, when I try to copy it back into hfs I get:
hcopy: "./FreeHand_5.0.1.bin": error seeking medium (Invalid argument)
These .bin files are recognized by ``macutils''.
I think the problem is that the source doesn't compile properly
on my PC - linux-2.4.19, Athlon, gcc 2.96.
Can somebody help me? (I think the problem could be in me too :) )
Sincerely,
Marcin
(I tried to use kernel hfs driver, too: I tried this way:
1) I extracted file.bin with macunpack into file.data, file.rsrc, and file.info
2) I copied file.data into hfs directory as ``file''
3) I copied file.rsrc into .resources (or sth like this) directory as ``file''
It doesn't work too - I see my file as plain document :(
)
From m.siennicki@cloos.pl Thu Aug 22 21:12:11 2002
From: m.siennicki@cloos.pl (m.siennicki@cloos.pl)
Date: Thu, 22 Aug 2002 22:12:11 +0200
Subject: [hfs-user] Problems with MacBinaries - first solution
In-Reply-To: <20020821002750.A4049@mimi.domek.foo>; from m.siennicki@cloos.pl on Wed, Aug 21, 2002 at 12:27:50AM +0200
References: <20020821002750.A4049@mimi.domek.foo>
Message-ID: <20020822221211.A7329@mimi.domek.foo>
--OXfL5xGRrasGEqWY
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
On Wed, Aug 21, 2002 at 12:27:50AM +0200, m.siennicki@cloos.pl wrote:
> I think the problem is that the source doesn't compile properly
And I'm right :) Linux users on ix86 should add (after doing ./configure)
following defines in Makefile, and libhfs/Makefile:
there is:
DEFINES = -DHAVE_CONFIG_H
there should be:
DEFINES = -DHAVE_CONFIG_H -D_FILE_OFFSET_BITS=64
it lets to do long seeks on /dev/sdX. It solves the problem
with hqx file (there was ``error seeking media''). I'll
try to find solution for wrong counted crc in MacBinary,
but maybe somebody knows it already?
(I attach the patch for Intel x86 users:
Copy it into hfsutils-3.2.6/ directory, then do:
$ patch -p1 < hfsutils-3.2.6-1.patch
Then configure, make, etc..., you do won't have to edit Makefiles.
I hope it can help somebody.)
Sincerely,
Marcin
--OXfL5xGRrasGEqWY
Content-Type: text/plain; charset=us-ascii
Content-Disposition: attachment; filename="hfsutils-3.2.6-1.patch"
--- hfsutils-3.2.6/configure Tue Nov 3 00:33:47 1998
+++ hfsutils-3.2.6.new/configure Thu Aug 22 21:53:02 2002
@@ -591,6 +591,16 @@
{ echo "configure: error: --with-tk requires --with-tcl" 1>&2; exit 1; }
fi
+echo -n "checking the machine type ..."
+MACHINE_TYPE=`uname -m`
+MACHINE_CLASS=$MACHINE_TYPE
+case "$MACHINE_TYPE" in
+ i385|i486|i586|i686)
+ MACHINE_CLASS="ix86"
+ ;;
+esac
+
+echo "$MACHINE_TYPE/$MACHINE_CLASS"
echo $ac_n "checking whether ${MAKE-make} sets \${MAKE}""... $ac_c" 1>&6
echo "configure:597: checking whether ${MAKE-make} sets \${MAKE}" >&5
@@ -1716,6 +1726,10 @@
DEFS=-DHAVE_CONFIG_H
+if test "$MACHINE_CLASS" = "ix86"; then
+ DEFS="$DEFS -D_FILE_OFFSET_BITS=64"
+fi
+
# Without the "./", some shells look in PATH for config.status.
: ${CONFIG_STATUS=./config.status}
--OXfL5xGRrasGEqWY--
From Pierre Duhem Fri Sep 20 10:40:16 2002
From: Pierre Duhem (Pierre Duhem)
Date: Fri, 20 Sep 2002 11:40:16 +0200
Subject: [hfs-user] Last mounted version in HFS+
Message-ID: <6211481154.20020920114016@duhem.com>
Hello,
I'm new to this list and searched the archive about the last mounted
version in the HFS+ Volume Header Block. The spec says that external
apps creating or modifying HFS+ volumes should use a creator code in
this slot.
Mark Day answered, in a message from april :
>> myVolHeader.lastMountedVersion=kHFSPlusMountVersion; //
>> implementation version which last mounted volume
>You should pick some other constant unique to your implementation. That
>way, if a bug is found in your implementation, other implementations can
>check this version to correct for the bug.
When I pass my volume through Norton, I get an error on this precise
point.
Who should I believe?
--
Best Regards
Pierre Duhem
Logiciels & Services Duhem, Paris (France)
duhem@macdisk.com
From Pierre Duhem Fri Sep 20 13:42:59 2002
From: Pierre Duhem (Pierre Duhem)
Date: Fri, 20 Sep 2002 14:42:59 +0200
Subject: Re[2]: [hfs-user] Last mounted version in HFS+
In-Reply-To: <3D8B0E62.5C7E0F84@eyeeye.com>
References: <6211481154.20020920114016@duhem.com> <3D8B0E62.5C7E0F84@eyeeye.com>
Message-ID: <16922445740.20020920144259@duhem.com>
Simon,
SB> At a guess I'd say Norton is picking up on exactly that point. Yes
SB> its great you've used a unique identifier, no Norton doesn't know
SB> anything about it, so doesn't no how to react. What should an
SB> arbretary piece of software do about a file system wuth an unknown
SB> unique identifier?
Since the spec is so clear, I thought that the author of Norton Disk
Doctor would have accepted any value in this slot.
[snip]
SB> In short, if you really have to, change the value to something
SB> that works quietly.
The problem is that many users check their media with Norton and whine
when it barks. I remember many problems with the bundle bit and with
the modification date.
Thanks for your answer.
--
Best Regards
Pierre Duhem
Logiciels & Services Duhem, Paris (France)
duhem@macdisk.com
From mday@apple.com Fri Sep 20 17:43:43 2002
From: mday@apple.com (Mark Day)
Date: Fri, 20 Sep 2002 09:43:43 -0700
Subject: [hfs-user] Last mounted version in HFS+
In-Reply-To: <6211481154.20020920114016@duhem.com>
Message-ID: <1FBD3142-CCB8-11D6-BCDB-00039354009A@apple.com>
On Friday, September 20, 2002, at 02:40 AM, Pierre Duhem wrote:
> I'm new to this list and searched the archive about the last mounted
> version in the HFS+ Volume Header Block. The spec says that external
> apps creating or modifying HFS+ volumes should use a creator code in
> this slot.
>
> Mark Day answered, in a message from april :
>>> myVolHeader.lastMountedVersion=kHFSPlusMountVersion; //
>>> implementation version which last mounted volume
>> You should pick some other constant unique to your implementation.
>> That
>> way, if a bug is found in your implementation, other implementations
>> can
>> check this version to correct for the bug.
>
> When I pass my volume through Norton, I get an error on this precise
> point.
>
> Who should I believe?
Me. :-)
The fact that Norton Disk Doctor (or at least some versions) complains
about an unrecognized signature is a bug in Disk Doctor. I think they
simply misunderstood the purpose of that field when they did their
first HFS Plus compatible product.
Mac OS X puts a different signature there than does Mac OS 8/9. And if
we ever make any significant changes in the part of the code that
handles the on-disk structures, we will probably use yet another
signature. Older versions of Disk Doctor complained about the Mac OS X
signature, but current versions don't seem to. I don't know whether
Disk Doctor now has a list of known signatures, or if they allow any
value.
On Friday, September 20, 2002, at 05:42 AM, Pierre Duhem wrote:
> Since the spec is so clear, I thought that the author of Norton Disk
> Doctor would have accepted any value in this slot.
Or at least make it sound less worrisome (a "note" rather than "disk
corruption").
> The problem is that many users check their media with Norton and whine
> when it barks. I remember many problems with the bundle bit and with
> the modification date.
I know what you mean. By all means write up bugs against Disk Doctor
if they complain about something they shouldn't. It would certainly be
nice if they were clearer about the severity of the inconsistencies
they find.
-Mark
From simon@eyeeye.com Fri Sep 20 13:02:43 2002
From: simon@eyeeye.com (Simon Bazley)
Date: Fri, 20 Sep 2002 13:02:43 +0100
Subject: [hfs-user] Last mounted version in HFS+
References: <6211481154.20020920114016@duhem.com>
Message-ID: <3D8B0E62.5C7E0F84@eyeeye.com>
At a guess I'd say Norton is picking up on exactly that point. Yes its great you've used a unique identifier, no Norton doesn't know anything about it, so doesn't no how to react. What should an arbretary piece of software do about a file system wuth an
unknown unique identifier?
My gut feeling is to treat a unique identifier as if it were apple, unless you know something (ie say symantec started doing stuff, I bet they have a number norton knows about).
If Norton haven't implemented it this way, then you'll have to either ignore the error, if you can, (which would be my preference) or lie to norton about who last made changes to the drive. The later would work, but if there are errors in your
implementation there is no way for other clever utilities to identify whats yours and whats not.
In short, if you really have to, change the value to something that works quietly.
Simon
From Pierre Duhem Thu Sep 26 13:29:12 2002
From: Pierre Duhem (Pierre Duhem)
Date: Thu, 26 Sep 2002 14:29:12 +0200
Subject: [hfs-user] Last mounted version in HFS+
In-Reply-To: <1FBD3142-CCB8-11D6-BCDB-00039354009A@apple.com>
References: <1FBD3142-CCB8-11D6-BCDB-00039354009A@apple.com>
Message-ID: <2022498242.20020926142912@duhem.com>
Mark,
MD> Mac OS X puts a different signature there than does Mac OS 8/9. And if
MD> we ever make any significant changes in the part of the code that
MD> handles the on-disk structures, we will probably use yet another
MD> signature. Older versions of Disk Doctor complained about the Mac OS X
MD> signature, but current versions don't seem to.
On my older 6100, under 8.1, I get "8.10". On my new eMac under OS X, I get
"10.0". I still have to upgrade it to Jaguar and will see what gives.
--
Best Regards
Pierre Duhem
Logiciels & Services Duhem, Paris (France)
duhem@macdisk.com
From Pierre Duhem Thu Sep 26 15:52:47 2002
From: Pierre Duhem (Pierre Duhem)
Date: Thu, 26 Sep 2002 16:52:47 +0200
Subject: [hfs-user] Floppy formatting
In-Reply-To: <1FBD3142-CCB8-11D6-BCDB-00039354009A@apple.com>
References: <1FBD3142-CCB8-11D6-BCDB-00039354009A@apple.com>
Message-ID: <1831114722.20020926165247@duhem.com>
Hello,
In the past years, I've seen many times formatting utilities which
formatted removable media as floppies, that is, without partition
table and with the MBR (signature BR) in the 2nd sector.
When I test such a scheme under Norton Disk Doctor v. 5, the disk
passes, with some residual errors.
I'm now testing also under NDD 7 and Disk Utility, under OS X.1.4, and
the disk never mounts.
Is such a formatting scheme deprecated?
Under NDD 5, the program complains about the block size (I chose 4KB,
as I had noted from other media) and insists on having 512B sectors.
Does this make sense?
Thanks in advance.
--
Best Regards
Pierre Duhem
Logiciels & Services Duhem, Paris (France)
duhem@macdisk.com
From Pierre Duhem Thu Sep 26 16:57:05 2002
From: Pierre Duhem (Pierre Duhem)
Date: Thu, 26 Sep 2002 17:57:05 +0200
Subject: [hfs-user] Floppy formatting
In-Reply-To: <3D9325A7.64CE7176@eyeeye.com>
References: <1FBD3142-CCB8-11D6-BCDB-00039354009A@apple.com>
<1831114722.20020926165247@duhem.com> <3D9325A7.64CE7176@eyeeye.com>
Message-ID: <6134972539.20020926175705@duhem.com>
Simon,
SB> 4kb is the default block size for HFS+, 512B is the default for
SB> HFS. My understanding is that having a device without parition
SB> table is the norm for small devices.
Where does this "default block size" come? In my understanding, the
formatter sets the block size in the MBR (or in the VHB for HFS+). I
have already seen floppies formatted in HFS with 1024B/sector and they
seem to work OK.
On the other hand, I never had a formatter which formatted as a floppy
(I used Silver lining, FWB, Apple's own tools, Drivor, Formac's
formatter and many others). But I saw many media formatted as
floppies.
SB> Are you sure you have HFS support?
Yes. HFS and HFS+, under OS 8.1 and 10.1.4.
--
Bien à vous
Pierre Duhem
mailto:lsduhem@duhem.com
From Pierre Duhem Thu Sep 26 17:01:09 2002
From: Pierre Duhem (Pierre Duhem)
Date: Thu, 26 Sep 2002 18:01:09 +0200
Subject: [hfs-user] Floppy formatting
In-Reply-To: <3D932602.F7EC4D48@eyeeye.com>
References: <1FBD3142-CCB8-11D6-BCDB-00039354009A@apple.com>
<1831114722.20020926165247@duhem.com> <3D932602.F7EC4D48@eyeeye.com>
Message-ID: <19835217167.20020926180109@duhem.com>
Bonjour Simon,
Le jeudi 26 septembre 2002, à 17:21, vous écriviez :
SB> Note thought that under HFS+ blocks size can be changed. Under HFS
SB> it MUST be 512bytes.
I don't think this is true. My formatter computes the block size with
a simple division: 1 + (nb_sectors / 0xFFFF). I think I found this
formula on some Apple document (Inside Macintosh ?).
SB> Changing it means its not a HFS disk anymore.
SB> Perhaps HFS+ requires a partition table. Have a read of Technote
SB> TN1150 for more information (regarding HFS+)
I read TN1150 several times along the years, from one of the first
editions, in 1999. I didn't read anything about the need of a
partition table. That is what one should conclude from reading IM and
other documents, but it is never stated so clearly. On the other hand,
I already saw many such media.
--
Best Regards
Pierre Duhem
Logiciels & Services Duhem, Paris (France)
duhem@macdisk.com
From mday@apple.com Thu Sep 26 19:05:59 2002
From: mday@apple.com (Mark Day)
Date: Thu, 26 Sep 2002 11:05:59 -0700
Subject: [hfs-user] Last mounted version in HFS+
In-Reply-To: <2022498242.20020926142912@duhem.com>
Message-ID: <9C9AF844-D17A-11D6-A4AC-00039354009A@apple.com>
On Thursday, September 26, 2002, at 05:29 AM, Pierre Duhem wrote:
> On my older 6100, under 8.1, I get "8.10".
All the way up to Mac OS 9.2.2 use '8.10', though we really should have
been changing that as we made significant changes or fixes.
> On my new eMac under OS X, I get
> "10.0". I still have to upgrade it to Jaguar and will see what gives.
Jaguar still uses '10.0'. It arguable that it should have changed the
lastMountedVersion, too.
-Mark
From garyliu@fas.harvard.edu Thu Sep 26 19:24:46 2002
From: garyliu@fas.harvard.edu (Gary Liu)
Date: Thu, 26 Sep 2002 14:24:46 -0400
Subject: [hfs-user] Last mounted version in HFS+
In-Reply-To: <9C9AF844-D17A-11D6-A4AC-00039354009A@apple.com>
Message-ID: <000401c2658a$010f7e40$0b5a93ac@GARYLIU>
Somebody please tell me how to get off this mailing list.
Thanks.
-----Original Message-----
From: hfs-user-admin@lists.mars.org
[mailto:hfs-user-admin@lists.mars.org] On Behalf Of Mark Day
Sent: Thursday, September 26, 2002 2:06 PM
To: Pierre Duhem
Cc: hfs-user-admin@lists.mars.org; hfs-user@lists.mars.org
Subject: Re: [hfs-user] Last mounted version in HFS+
On Thursday, September 26, 2002, at 05:29 AM, Pierre Duhem wrote:
> On my older 6100, under 8.1, I get "8.10".
All the way up to Mac OS 9.2.2 use '8.10', though we really should have
been changing that as we made significant changes or fixes.
> On my new eMac under OS X, I get
> "10.0". I still have to upgrade it to Jaguar and will see what gives.
Jaguar still uses '10.0'. It arguable that it should have changed the
lastMountedVersion, too.
-Mark
From pwd@apple.com Fri Sep 27 00:28:56 2002
From: pwd@apple.com (Patrick Dirks)
Date: Thu, 26 Sep 2002 16:28:56 -0700
Subject: [hfs-user] Floppy formatting
In-Reply-To: <19835217167.20020926180109@duhem.com>
Message-ID:
On Thursday, September 26, 2002, at 09:01 AM, Pierre Duhem wrote:
> Bonjour Simon,
>
> Le jeudi 26 septembre 2002, à 17:21, vous écriviez :
>
> SB> Note thought that under HFS+ blocks size can be changed. Under HFS
> SB> it MUST be 512bytes.
>
> I don't think this is true. My formatter computes the block size with
> a simple division: 1 + (nb_sectors / 0xFFFF). I think I found this
> formula on some Apple document (Inside Macintosh ?).
Um, not sure exactly what you're trying to do but this could be
trouble. On HFS the allocation block size was, by default, the
smallest multiple of 512 bytes that would make the total number of
allocation blocks fit in 16 bits. On HFS+, however, the allocation
block size must be a power of two multiple of 512, i.e. 512 bytes, 1K,
2K, 4K, 8K, etc. 3K, for instance, would NOT be a valid allocation
block size!
See TN1150 (bottom of page 4).
>
> SB> Changing it means its not a HFS disk anymore.
> SB> Perhaps HFS+ requires a partition table. Have a read of Technote
> SB> TN1150 for more information (regarding HFS+)
>
> I read TN1150 several times along the years, from one of the first
> editions, in 1999. I didn't read anything about the need of a
> partition table. That is what one should conclude from reading IM and
> other documents, but it is never stated so clearly. On the other hand,
> I already saw many such media.
>
>
> --
> Best Regards
> Pierre Duhem
> Logiciels & Services Duhem, Paris (France)
> duhem@macdisk.com
>
From simon@eyeeye.com Thu Sep 26 16:20:07 2002
From: simon@eyeeye.com (Simon Bazley)
Date: Thu, 26 Sep 2002 16:20:07 +0100
Subject: [hfs-user] Floppy formatting
References: <1FBD3142-CCB8-11D6-BCDB-00039354009A@apple.com> <1831114722.20020926165247@duhem.com>
Message-ID: <3D9325A7.64CE7176@eyeeye.com>
4kb is the default block size for HFS+, 512B is the default for HFS. My understanding is that having a device without parition table is the norm for small devices. Are you sure you have HFS support?
Simon
From simon@eyeeye.com Thu Sep 26 16:21:38 2002
From: simon@eyeeye.com (Simon Bazley)
Date: Thu, 26 Sep 2002 16:21:38 +0100
Subject: [hfs-user] Floppy formatting
References: <1FBD3142-CCB8-11D6-BCDB-00039354009A@apple.com> <1831114722.20020926165247@duhem.com>
Message-ID: <3D932602.F7EC4D48@eyeeye.com>
Note thought that under HFS+ blocks size can be changed. Under HFS it MUST be 512bytes. Changing it means its not a HFS disk anymore. Perhaps HFS+ requires a partition table. Have a read of Technote TN1150 for more information (regarding HFS+)
Simon
From simon@eyeeye.com Thu Sep 26 18:15:41 2002
From: simon@eyeeye.com (Simon Bazley)
Date: Thu, 26 Sep 2002 18:15:41 +0100
Subject: [hfs-user] Floppy formatting
References: <1FBD3142-CCB8-11D6-BCDB-00039354009A@apple.com>
<1831114722.20020926165247@duhem.com> <3D932602.F7EC4D48@eyeeye.com> <19835217167.20020926180109@duhem.com>
Message-ID: <3D9340BD.4DE85DB1@eyeeye.com>
The default block size is specified in Inside Macintosh: Files page 2-54 and 2-56. It states that the default macintosh block size is 512 bytes. Each device is conceptually a physical and logical device, the physical one being what in linux is a block
device (that happens to be a hard disk), logical one being on a per volume basis. All Physical devices are 512 byte blocks, this is stated on 2-54, and discussed further in Inside Macintosh: Devices, SCSI Manager (3-12).
All code relating to the partition table, takes place at device level, rather than file system level. This all changed with HFS+
I think the thing you're confusing is logical block size, which is stated as the lowest multiple of 512 such that less than 65535 blocks exist on the volume, and physical block size (always 512).
It states (2-54) that the organisation of a floppy disk doesn't include partitions (and hence can't include device drivers), wheras hard disks do. Perhaps this has something to do with it.
This is all fairly academic if you're using HFS+ though, which I think sounds like the best idea.
Simon
From Frank Meurer Sat Sep 28 11:01:15 2002
From: Frank Meurer (Frank Meurer)
Date: Sat, 28 Sep 2002 12:01:15 +0200 (CEST)
Subject: [hfs-user] Floppy formatting
In-Reply-To: <3D932602.F7EC4D48@eyeeye.com>
Message-ID:
On Thu, 26 Sep 2002, Simon Bazley cum veritate scripsit :
> Note thought that under HFS+ blocks size can be changed. Under HFS it
> MUST be 512bytes. Changing it means its not a HFS disk anymore.
[...]
Just a small note: You can use HFS 512 byte block sizes even if your drive
is formatted with other block sizes (i.e. 4k blocks). This is a layer
beyond HFS. Don't mix it up! ;-)
OT:
Thank you all for the information given on this list (just wanted to say
it)!
--
Sending unsolicited commercial email to this address may be a violation
of the Washington State Consumer Protection Act, chapter 19.86 RCW.
Das Verschicken unverlangter kommerzieller email an diese Adresse ist
verboten (LG Traunstein, 2 HK O 3755/97 vom 14.10.1997, CR 1998, 171f).
From jcpearso@ps.ucl.ac.uk Wed Oct 2 16:09:45 2002
From: jcpearso@ps.ucl.ac.uk (James Pearson)
Date: Wed, 02 Oct 2002 16:09:45 +0100
Subject: [hfs-user] HFS utils and large volumes
Message-ID: <413754.1033571385@ourhome.freeserve.co.uk>
In case anyone is interested, here is a small patch to make hfsutils work
with large volumes (over 4Gb).
Under Linux, I also has to compile the code with
"-D_FILE_OFFSET_BITS=64 -D_LARGEFILE_SOURCE"
(There is probably a way to do this via 'configure', but I haven't a clue
how to do that ...)
The only strange bit about the the patch is that I had to split the
"return" line into two lines - which is the only way it would gives
the correct result using gcc v2.96-98 on Linux for large numbers ...
James Pearson
*** hfsutils-3.2.6/libhfs/os/unix.c.dist Mon Nov 2 22:09:13 1998
--- hfsutils-3.2.6/libhfs/os/unix.c Wed Oct 2 13:46:29 2002
***************
*** 147,158 ****
if (offset == (unsigned long) -1)
result = lseek(fd, 0, SEEK_END);
else
! result = lseek(fd, offset << HFS_BLOCKSZ_BITS, SEEK_SET);
if (result == -1)
ERROR(errno, "error seeking medium");
! return (unsigned long) result >> HFS_BLOCKSZ_BITS;
fail:
return -1;
--- 147,160 ----
if (offset == (unsigned long) -1)
result = lseek(fd, 0, SEEK_END);
else
! result = lseek(fd, (off_t)offset << HFS_BLOCKSZ_BITS, SEEK_SET);
if (result == -1)
ERROR(errno, "error seeking medium");
! result >>= HFS_BLOCKSZ_BITS;
!
! return (unsigned long) result;
fail:
return -1;
From jcpearso@ps.ucl.ac.uk Thu Oct 3 16:45:07 2002
From: jcpearso@ps.ucl.ac.uk (James Pearson)
Date: Thu, 03 Oct 2002 16:45:07 +0100
Subject: [hfs-user] HFS utils and large volumes
In-Reply-To: Your message of Wed, 02 Oct 2002 16:09:45 +0100.
<413754.1033571385@ourhome.freeserve.co.uk>
Message-ID: <382331.1033659907@ourhome.freeserve.co.uk>
>In case anyone is interested, here is a small patch to make hfsutils work
>with large volumes (over 4Gb).
>
>Under Linux, I also has to compile the code with
>
> "-D_FILE_OFFSET_BITS=64 -D_LARGEFILE_SOURCE"
>
>(There is probably a way to do this via 'configure', but I haven't a clue
>how to do that ...)
>
>The only strange bit about the the patch is that I had to split the
>"return" line into two lines - which is the only way it would gives
>the correct result using gcc v2.96-98 on Linux for large numbers ...
I missed that hfsutils reports the number free bytes on a volume - which
overflow a 32 bit integer for volumes over 4Gb - the following replacement
patch should fix this.
James Pearson
begin 664 hfsutils-3.2.6-lfs-2.patch.gz
M'XL(")UAG#T``VAFY:W=T>C2ZQIY>R7IY$G[M^-X@8
M5\[2!";I-8`%EN48^XYI@[F_/]S2=?TI!N4]"6#J_ZUC[8!F&M=6N
M?T0;S/Y>QQP,078`?J(0U#0,&>%P<`!JGK!HD2`C39.%!KJIR5D`&6$YQ3E`
M&2%7:AATP.B`.QZ_FX\G)]I(3B,XN+7=-+]L6@O=DK^]SH9G2+#S-""H(:_@UV'R.\";]Y
M'(]>TM2_8C=UBLW)Y4R?YO$*Y]W9[&NZDO.$^I5HI25^OFCU%"OR['N%?(+S
M6<1]W!C+)F.8WV*,Y1UC]$W'M!XQQJ#3MVZ+AK_T,DB\F'P443L[^FU^<3J>
MP$LP/XV47EL.X74O#I7C+_7,\Z!2*4*(<)0%"[^/6,9=`T7H(5X:S#EW'=;2Q2X]B
MG\T8Z+2]9IL-[;W.L&]71E-`T.*!\;80-T9YSQ3=
M\VO&/2[NU0[LX*`F;C8<8JL,0QRJ^(=D*_VP*,!8XU_0'/#;Z@BJ;A7,HK6.
MCJSYRM?RD5"\2.0;@O',CU>JERVN/YJ?D,[/`H^3EB:>%89X52A_22&J,Y39
M^Z//(`_Q
Message-ID: <406059.1033659322@ourhome.freeserve.co.uk>
>In case anyone is interested, here is a small patch to make hfsutils work
>with large volumes (over 4Gb).
>
>Under Linux, I also has to compile the code with
>
> "-D_FILE_OFFSET_BITS=64 -D_LARGEFILE_SOURCE"
>
>(There is probably a way to do this via 'configure', but I haven't a clue
>how to do that ...)
>
>The only strange bit about the the patch is that I had to split the
>"return" line into two lines - which is the only way it would gives
>the correct result using gcc v2.96-98 on Linux for large numbers ...
I missed that hfsutils reports the number free bytes on a volume - which
overflow a 32 bit integer for volumes over 4Gb - the following replacement
patch should fix this.
James Pearson
begin 664 hfsutils-3.2.6-lfs-2.patch.gz
M'XL(")UAG#T``VAFY:W=T>C2ZQIY>R7IY$G[M^-X@8
M5\[2!";I-8`%EN48^XYI@[F_/]S2=?TI!N4]"6#J_ZUC[8!F&M=6N
M?T0;S/Y>QQP,078`?J(0U#0,&>%P<`!JGK!HD2`C39.%!KJIR5D`&6$YQ3E`
M&2%7:AATP.B`.QZ_FX\G)]I(3B,XN+7=-+]L6@O=DK^]SH9G2+#S-""H(:_@UV'R.\";]Y
M'(]>TM2_8C=UBLW)Y4R?YO$*Y]W9[&NZDO.$^I5HI25^OFCU%"OR['N%?(+S
M6<1]W!C+)F.8WV*,Y1UC]$W'M!XQQJ#3MVZ+AK_T,DB\F'P443L[^FU^<3J>
MP$LP/XV47EL.X74O#I7C+_7,\Z!2*4*(<)0%"[^/6,9=`T7H(5X:S#EW'=;2Q2X]B
MG\T8Z+2]9IL-[;W.L&]71E-`T.*!\;80-T9YSQ3=
M\VO&/2[NU0[LX*`F;C8<8JL,0QRJ^(=D*_VP*,!8XU_0'/#;Z@BJ;A7,HK6.
MCJSYRM?RD5"\2.0;@O',CU>JERVN/YJ?D,[/`H^3EB:>%89X52A_22&J,Y39
M^Z//(`_Q
Message-ID: <19345.1035557487@www26.gmx.net>
--- Weitergeleitete Nachricht / Forwarded Message ---
Date: Fri, 25 Oct 2002 16:47:39 +0200 (MEST)
From: nand@gmx.de
To: hfs-user@lists.apple.com
Subject: FinderInfo
> Hello Listers,
> Does anyone know what the 32 bytes of FinderInfo in the
> MDB/VolmeHeader of an HFS/HFS+ volume are actually supposed to contain ?
>
> Neither Universal Interfaces or TN 1150 seem to mention the exact format
> of
> the data stored in here. Some sample driver code from Apple led me to
> believe
> that these 32 bytes are organized as eight 4 byte units of which the fifth
> long integer holds the CNID of the System Folder of the Volume (if
> present).
> What do the other fields stand for... could someone direct me links
> describing
> these if any?
> The weblinks point to Inside Macintosh: Finder but only the finder fields
> relevant to the catalog files and folders seem to be described here.
>
> Any help is greatly appreciated!
>
> Regards,
> Nandini Hengen
>
> --
> +++ GMX - Mail, Messaging & more http://www.gmx.net +++
> NEU: Mit GMX ins Internet. Rund um die Uhr für 1 ct/ Min. surfen!
>
>
--
+++ GMX - Mail, Messaging & more http://www.gmx.net +++
NEU: Mit GMX ins Internet. Rund um die Uhr für 1 ct/ Min. surfen!