[Mac] file copy

[Tobias Weber]

Hi,
which is the best way to copy files on OS X? I want to preserve resource
forks and extended attributes.

shutil.copy2

bin/cp -p

py-appscript the Finder

PyObjC NSFileManager

 

[Diez B. Roggisch]

Hi,
which is the best way to copy files on OS X? I want to preserve resource
forks and extended attributes.

Are these still relevant on OSX? I've always only copied files directly, and
never had any troubles.

Diez

 

[Philip Semanchuk]

Are these still relevant on OSX? I've always only copied files
directly, and
never had any troubles.

I think resource forks are now stored as extended attributes, and
Apple's version of cp is aware of extended attributes.

Try this -- create a text file via terminal using `touch foo.txt`. In
Finder, click "get info" on the file and change it to open with
anything other than TextEdit (e.g. Firefox).

Now go back to terminal and look at the file. It's still zero bytes
long, but try the command `xattr foo.txt` --

$ xattr foo.txt
com.apple.FinderInfo
com.apple.ResourceFork

Also --
$ cp foo.txt bar.txt
$ xattr bar.txt
com.apple.FinderInfo
com.apple.ResourceFork

xattr -h gives options for this command.

To the OP -- I remember reading somewhere that xattr is written in
Python. You might find it useful or even be able to import it directly.


HTH
Philip

 

[Tobias Weber]

Are these still relevant on OSX? I've always only copied files directly, and
never had any troubles.

Not a useful attitude. You never know what files you get. There is a lot
of old-fashioned software around.

 

[Tobias Weber]

I think resource forks are now stored as extended attributes, and
No

Apple's version of cp is aware of extended attributes.

Yes, but the manual doesn't say to what extent, nor anything about ACLs

Try this -- create a text file via terminal using `touch foo.txt`. In

Don't have time to do something like the outdated
http://blog.plasticsfuture.org/2006/04/23/mac-backup-software-harmful/

Was hoping someone already knows...

To the OP -- I remember reading somewhere that xattr is written in
Python. You might find it useful or even be able to import it directly.

It uses a C extension, but I could import it if I wanted to re-invent
the wheel

 

[Philip Semanchuk]

No

I'll take your word for it because I was just guessing, but then why
do the xattrs in the example I gave show a resource fork?

Yes, but the manual doesn't say to what extent, nor anything about
ACLs

Your original question didn't say anything about ACLs either.

It uses a C extension, but I could import it if I wanted to re-invent
the wheel

Isn't importing a module that's already written the exact opposite of
re-inventing the wheel?

 

[Tobias Weber]

I'll take your word for it because I was just guessing, but then why
do the xattrs in the example I gave show a resource fork?

As I understand it that's a convenience mapping for what's still stored
the same old way. No idea if copying that attribute is sufficient.

 

[Michael Torrie]

Yes, but the manual doesn't say to what extent, nor anything about ACLs

mv, cp, etc (but not rsync) are completely aware of resource forks from
Tiger on. This is well documented and known on the Mac forums.

So shutils should work just fine for copying, moving, etc.

 

[Jerry Hill]

mv, cp, etc (but not rsync) are completely aware of resource forks from
Tiger on.  This is well documented and known on the Mac forums.

So shutils should work just fine for copying, moving, etc.

I don't think that's true. The shutil docs
(http://docs.python.org/library/shutil.html) has a big red box at the
top that says:

"""
Warning

Even the higher-level file copying functions (copy(), copy2()) can’t
copy all file metadata.

On POSIX platforms, this means that file owner and group are lost as
well as ACLs. On Mac OS, the resource fork and other metadata are not
used. This means that resources will be lost and file type and creator
codes will not be correct. On Windows, file owners, ACLs and alternate
data streams are not copied.
"""

If I understand the OP's question from the first email in this thread,
that should pretty strongly warn you that shutil.copy2 is not going to
do what you want. Not being a mac user myself, I don't know what the
right way to accomplish what you want is, though.

 

[Tobias Weber]

mv, cp, etc (but not rsync) are completely aware of resource forks from
Tiger on. This is well documented and known on the Mac forums.

So shutils should work just fine for copying, moving, etc.

Why "so"? shutil does not use bin/cp!

 

[Miles Kaufmann]

Hi,
which is the best way to copy files on OS X? I want to preserve
resource
forks and extended attributes.

...

bin/cp -p

This. cp -p, mv, rsync -E, tar, and other utilities will use the
copyfile(3) API to preserve extended attributes, resource forks, and
ACLs. cp -Rp should be just as safe as a Finder copy--moreso if you
run it as root--with the exception of preserving creation dates. Or
if you're worried about hard links, check out ditto(1).

You presumably already know this, but avoid shutil at all costs.

BackupBouncer (http://www.n8gray.org/code/backup-bouncer/) makes
testing what gets preserved by various methods of copying quick and
easy.

The results for a Finder copy:

Verifying: basic-permissions ... FAIL (Critical)
Verifying: timestamps ... ok (Critical)
Verifying: symlinks ... ok (Critical)
Verifying: symlink-ownership ... FAIL
Verifying: hardlinks ... FAIL (Important)
Verifying: resource-forks ...
Sub-test: on files ... ok (Critical)
Sub-test: on hardlinked files ... FAIL (Important)
Verifying: finder-flags ... ok (Critical)
Verifying: finder-locks ... ok
Verifying: creation-date ... ok
Verifying: bsd-flags ... ok
Verifying: extended-attrs ...
Sub-test: on files ... ok (Important)
Sub-test: on directories ... ok (Important)
Sub-test: on symlinks ... ok
Verifying: access-control-lists ...
Sub-test: on files ... ok (Important)
Sub-test: on dirs ... ok (Important)
Verifying: fifo ... FAIL
Verifying: devices ... FAIL
Verifying: combo-tests ...
Sub-test: xattrs + rsrc forks ... ok
Sub-test: lots of metadata ... FAIL

sudo cp -Rp:

Verifying: basic-permissions ... ok (Critical)
Verifying: timestamps ... ok (Critical)
Verifying: symlinks ... ok (Critical)
Verifying: symlink-ownership ... ok
Verifying: hardlinks ... FAIL (Important)
Verifying: resource-forks ...
Sub-test: on files ... ok (Critical)
Sub-test: on hardlinked files ... FAIL (Important)
Verifying: finder-flags ... ok (Critical)
Verifying: finder-locks ... ok
Verifying: creation-date ... FAIL
Verifying: bsd-flags ... ok
Verifying: extended-attrs ...
Sub-test: on files ... ok (Important)
Sub-test: on directories ... ok (Important)
Sub-test: on symlinks ... ok
Verifying: access-control-lists ...
Sub-test: on files ... ok (Important)
Sub-test: on dirs ... ok (Important)
Verifying: fifo ... ok
Verifying: devices ... ok
Verifying: combo-tests ...
Sub-test: xattrs + rsrc forks ... ok
Sub-test: lots of metadata ... ok

-Miles

 

[Michael Torrie]

Why "so"? shutil does not use bin/cp!

That's good to know. I had always thought that that was what shutils
did, but you're right; it does not.

That said, since cp indeed *can* copy resource forks on Tiger and up,
you could use subprocess to call it.

Just as an aside, your response to a couple of the suggestions in this
thread has been a bit brusque, even given the normal limits of e-mail
communications. While it's true that nothing so far has been quite what
you wanted, I'm sure that everyone has certainly tried to help you find
a solution by throwing out different ideas! It is also true that for
many people resources forks are not at all necessary, which is probably
why someone mentioned that before, perhaps hoping to save you work.
Anyways, I certainly hope you do get something working.

 

[Tommy Nordgren]

Are these still relevant on OSX? I've always only copied files
directly, and
never had any troubles.

Diez
--

the cp command copies INCLUDING resource forks, since tiger.