[Pythonmac-SIG] Accessing Resource forks

[Donna and Chris Barker]

HI all,

Somehow over all these years, I've managed to use Python on MAcs
without having it deal with resource forks and sll that -- but
ironically, not that we're all OS-X all the time, I need to do ti now.

What I'm trying to do is simple check for the existance of a resource
fork, and if it's there, the size.


This is what I've tried:

import Carbon.File as File
files = ["junk.txt", "junk_rsc.txt"]

for filename in files:
    f = File.FSRef(filename)
    print "file path is:", f.FSRefMakePath()

    i = f.FSGetCatalogInfo(0)
    print "logical size is:", i[0].rsrcLogicalSize
    print "Physical size is:", i[0].rsrcPhysicalSize

In this case, junk.txt was created at the command line, so it
shouldn't have a resource fork. junk_rsc.txt I opened up in resedit,
which should have given it a small resource fork. Runnign this script,
I get:

file path is: /Users/cbarker/temp/AFP-SMB/junk.txt
logical size is: 65543
Physical size is: 30457855
file path is: /Users/cbarker/temp/AFP-SMB/junk_rsc.txt
logical size is: -593231776
Physical size is: -210763775

The paths are right, so it looks like I've got the FSRef right, but
rsrcLogicalSize and rsrcPhysicalSize make no sense.

How should I be doing this -- the docs are sparse, to say the least!

By the way, I might as well tell you the real goal, maybe one of you
will have a better idea.

We have a Windows file server that is about to be retired. over the
years, people of have put files on it using both the AFP and SMB
protocols (the server is running MS services for macintosh). These are
all mixed up. However, any file put up with one protocol loses it's
resource fork (and type and creator) if brought down with the other
protocol.

Our goal is to clean up this mess automatically.

The idea at hand is that a file brought down with AFP will either:

Have a nice resource fork, in which case it was put up with AFP, and we're happy
Have no resource fork, in which case it never had one, and we dont'
care what protocol was used, or it was put up with SMB, and we can
then bring it down that way instead.

The other obvious option is to look for the ._* files, which is where
the resource fork is stored with the SMB protocol. However, we're
concerned that that may not be reliable -- if a file were put up with
SMB, then replaced with AFP, there may be a ._* file, but it won't
work right. This actually seems pretty likely as while we have this
mixed system, there have been a lot of "that didn't work, please put
the file back up with APF" interations.

Thanks for your thoughts.

-Chris