[Pythonmac-SIG] Accessing Resource forks

[Christopher Barker]

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

Re: [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 <[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

Re: [Pythonmac-SIG] Accessing Resource forks

[Daniel Lord]

On Jul 13, 2007, at 2:55 PM, Christopher Barker wrote:
>
> 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.
>

RezDet command line utility perhaps?

as in:
[15:30:10] [EMAIL PROTECTED] ~/Pictures
$RezDet f*.jpg
"f3390b9f2ff8e50fb6772ab5bc7c3b2f.jpg":
File "f3390b9f2ff8e50fb6772ab5bc7c3b2f.jpg"; ### RezDet - The  
resource fork is empty and uninitialized.

Perhaos use 'commands.getstatusoutput' to run it and search result  
string?


It is listed as an MPW tool, but its still there in Tiger--just checked.

http://developer.apple.com/tools/mpw-tools/commandref/rezdet.html

Daniel
___
Pythonmac-SIG maillist  -  Pythonmac-SIG@python.org
http://mail.python.org/mailman/listinfo/pythonmac-sig

Re: [Pythonmac-SIG] Accessing Resource forks

[Christopher Barker]

Daniel Lord wrote:
> RezDet command line utility perhaps?

Yup, that looks very useful -- it just may be the solution.

I had no idea it was there, and it took a while to find it. Maybe it's 
time to add /Developer/Tools/ to my PATH.

thanks,

-Chris

(still wondering how to do it inside Python... What if I wanted to do 
something with a resource fork?)



-- 
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

Re: [Pythonmac-SIG] Accessing Resource forks

[Christopher Barker]

Hamish Allan wrote:
> 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?

The server is storing the resource forks somewhere, but not anywhere we
can see them - who knows?

> 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.

I'm only trying to use those after downloading the files via AFP. In my
test code, I'm using files created on the Mac they're being tested on,
so it should work, if I knew how.

> 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?

Good idea, why didn't I think of that?

> 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

Yup, that looks like a good option. I'll give it a try.

I'd still like to know how to get info in the Resource fork, however...

Thanks,

-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

Re: [Pythonmac-SIG] Accessing Resource forks

[Nicholas Riley]

On Fri, Jul 13, 2007 at 02:55:55PM -0700, Christopher Barker wrote:
> 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.

Yeah, SFM uses NTFS's "stream" support to store the resource fork and
other Mac specific metadata elsewhere.  You can check the resource
fork size by looking at "/path/to/file/..namedfork/rsrc" but since the
type and creator aren't stored in the resource fork, you'll have to
get those in other ways if you want to preserve them.

Note that forthcoming Mac OS X versions may no longer use ._ files to
store resource forks on SMB mounted volumes (some third-party clients
already don't), instead reading/writing to alternate streams just as
SFM does.

-- 
Nicholas Riley <[EMAIL PROTECTED]> | 
___
Pythonmac-SIG maillist  -  Pythonmac-SIG@python.org
http://mail.python.org/mailman/listinfo/pythonmac-sig

Re: [Pythonmac-SIG] Accessing Resource forks

[Nicholas Riley]

On Fri, Jul 13, 2007 at 03:56:16PM -0700, Christopher Barker wrote:
> Hamish Allan wrote:
> > 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?
> 
> The server is storing the resource forks somewhere, but not anywhere we
> can see them - who knows?

The resource forks live in the "AFP_Resource" stream, and the other
file info in the "AFP_AfpInfo" stream.  There's also a "Comments"
stream which used to be used for Finder comments, but I don't think OS
X uses it any more.

For those Windows apps (not all) that understand multiple streams, you
refer to them as "filename:streamname",
e.g. "c:\temp\foo:AFP_Resource".  But that's only useful if you're
looking at it on Windows; if you're viewing it from the Mac over AFP
then just use the Mac native mechanisms.

When doing a search I discovered the "Fork Server Helper" app which
might be useful to you, as it's designed to convert between resource
fork storage formats.



-- 
Nicholas Riley <[EMAIL PROTECTED]> | 
___
Pythonmac-SIG maillist  -  Pythonmac-SIG@python.org
http://mail.python.org/mailman/listinfo/pythonmac-sig