[Pythonmac-SIG] Accessing Resource forks

[Hamish Allan]

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