Sample hexdump output:
1. old resource fork: (netatalk-1.3.3st-6)
0000000 1607 0005 0000 0001 0000 0000 0000 0000
0000010 0000 0000 0000 0000 0500 0000 0200 0000
0000020 4d02 0000 de1e 0000 0300 0000 5600 0000
0000030 0900 0000 0400 0000 5501 0000 0000 0000
0000040 0700 0000 1d02 0000 1000 0000 0900 0000
0000050 2d02 0000 2000 2e30 3130 642e 6d79 0061
0000060 0000 0000 0000 0000 0000 0000 0000 0000
*
0000210 0000 0000 0000 0000 0000 0000 3200 4ce6
0000220 3298 bdf8 809b 0000 0000 0000 4500 5350
0000230 4146 5452 0135 0000 0035 0049 0000 0000
0000240 0000 0000 0000 0000 0000 0000 0000 0100
2. new resource fork(netatalk+asun2.1.3)
0000000 0500 0716 0100 0000 0000 0000 0000 0000
0000010 0000 0000 0000 0000 0500 0000 0200 0000
0000020 4d02 0000 de1e 0000 0300 0000 5600 0000
0000030 0900 0000 0400 0000 5501 0000 0000 0000
0000040 0700 0000 1d02 0000 1000 0000 0900 0000
0000050 2d02 0000 2000 2e30 3130 642e 6d79 0061
0000060 0000 0000 0000 0000 0000 0000 0000 0000
*
0000210 0000 0000 0000 0000 0000 0000 fa00 0979
0000220 fa18 7a8b 801b 0000 0000 0000 4500 5350
0000230 4146 5452 0135 ff00 ffff 00ff 0000 0000
0000240 0000 0000 0000 0000 0000 0000 0000 0100
If it's improperly created v1 AppleDouble headers,
then I'm probably better off running my files through
the copy procedure, to get rid of them (?) unless there
is a better method for going about it.
--rich
On Thu, 11 Mar 1999, a sun wrote:
>
> I notice that if I drag a file up to a network
> drive via my netatalk-1.3.3st-6 server, the
> icons don't show up right when viewed via the
> +asun2.1.3 server. That is, I have a single
> Macintosh with two windows open, each looking
> at the same file, but going through those two
> different servers. I am assuming that what I
> am seeing, is a difference due to v1 versus v2
> resource forks.
>
> this has nothing to do with v1 versus v2 resource forks. it has
> everything to do with improperly created v1 AppleDouble
> headers. asun2.1.3 tries to detect improperly created v1 headers, but
> it looks like there's more than one way to be broken. if people are
> getting -50 errors with asun2.1.3, send me a hexdump of the first few
> bytes of the .AppleDouble parts of the problem files. if there's a
> pattern, i'll add it to the list of things to check against. i don't
> want to keep putting cruft in there though, and i don't want to turn
> off the magic/version checks.
>
> believe it or not, being able to detect whether or not a file is
> really an AppleDouble header file is a good thing. if the appledouble
> routines had checked for the magic/version way in the beginning,
> people wouldn't be having this problem now.
>
> -a
> [EMAIL PROTECTED]
>
