Subject: [netatalk-admins] conversion from v1 to v2 resource forks

From: Richard Mann <[email-masked]>
Date: Thu, 11 Mar 1999 12:53:53 -0600 (CST)

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.

	If I do the same test over again, but this time the
	file originates via the +asun2.1.3 server, then the
	icon shows up properly on both. 

	I can do a mass copy from the old-version window to
	the new-version window, and voila, the resource forks
	now show up ok on both, recursively through the 
	directories.

	But, I don't want to change my modified dates, because
	that causes the Quark department a lot of headaches.

	Is there a way to do a mass conversion of v1 resource
	forks to v2, preserving file information otherwise? This
	won't be a one-time thing: whenever an archive from these
	past two years needs to be restored, I would have to process 
	those directories again. 

     //\     --rich
    //  \    
   // /  \   Richard Mann -- Systems Administrator
  // / /  \  P u b l i c a t i o n  S e r v i c e s,  I n c. 
  \\  / / /  Champaign, Illinois, USA 61821 (217) 398-2060 x36
   \\  / /     
    \\  /    http://www.pubserv.com  http://www.primesynergy.com 
     \\/

---

From: a sun <[email-masked]>
Date: Thu, 11 Mar 1999 11:24:59 -0800 (PST)

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-masked]

---

From: Richard Mann <[email-masked]>
Date: Thu, 11 Mar 1999 13:54:53 -0600 (CST)

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