[Pythonmac-SIG] Accessing Resource forks

Daniel Lord daniellord at mac.com
Mon Jul 30 12:04:42 CEST 2007


Chris, I know you already asked this and got answers, so I did not at  
first understand why you asked again.
Then I saw the date of the message. I think that in you search for a  
solution to handling antiquated resource forks, you might have  
discovered time travel as a side effect.
Patent what ever you did and quickly ;-)
Strange.

Daniel

On Jul 12, 2007, at 5:16 PM, Donna and Chris Barker wrote:

> 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
> _______________________________________________
> Pythonmac-SIG maillist  -  Pythonmac-SIG at python.org
> http://mail.python.org/mailman/listinfo/pythonmac-sig



More information about the Pythonmac-SIG mailing list