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