Hi Chris, Let me start by saying that I've never used MS services for Macintosh, so this is all guesswork. But the first thing I wondered was, if files uploaded over AFP aren't using ._* files, what are they using? Presumably the Windows machine isn't actually mounting an HFS or HFS+ filesystem, so they're being stored somewhere "non-standard", in which case all bets for using FSRef are off anyway.
Proceeding with this assumption, could you perhaps compare the modification times of the ._* files with the files for which they store the resource fork, and if the latter has a more recent modification time the chances are that it has been overwritten using AFP? That is to say, there are three cases: 1) No ._* file is present: Either the resource fork is stored in non-standard place due to AFP or the file never had one -- download via AFP 2) ._* file is present and has same modification time as its counterpart -- download via SMB 3) ._* file is present and has later modification time than its counterpart -- download via AFP Hope this helps, Hamish On 7/13/07, Christopher Barker <[EMAIL PROTECTED]> wrote: > Hi all, > > Somehow over all these years, I've managed to use Python on Macs > without having it deal with resource forks and all that -- but > ironically, now that we're all OS-X all the time, I need to do it now. > > What I'm trying to do is simple check for the existence 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. Running 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" iterations. > > Thanks for your thoughts. > > -Chris > > -- > Christopher Barker, Ph.D. > Oceanographer > > Emergency Response Division > NOAA/NOS/OR&R (206) 526-6959 voice > 7600 Sand Point Way NE (206) 526-6329 fax > Seattle, WA 98115 (206) 526-6317 main reception > > [EMAIL PROTECTED] > _______________________________________________ > 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
