[OpenAFS-port-darwin] Odd problem with file cp'ed from afs to local HD

[Garance A Drosihn]

I am running openafs on MacOS 10, and ran into an odd problem
when I copied a file from our local AFS cell to my hard disk.
(our AFS cell is all Transarc-afs servers, I am only using
OpenAFS on the client).

I have some bash-config files in my standard home directory
in AFS-land, and I merged some changes into them to work
better for MacOS 10, as well as all the other platforms they
work with.  I then did a:

        cp -p ~drosehn/.bash_aliases ~

where '~' is my home directory (on the local hard disk) on
my MacOS 10 system.  It is an HFS+ directory.

I noticed the following error message when I did it:

        cp: utimes: /Users/gad/aliasTest: Operation not permitted

I thought this was odd, but didn't really think too much
about it.  Of course, I didn't get things completely right
the first time, so I made a few more changes to the version
in AFS, and when to re-copy the file to my local HD.  Much
to my surprise, the *copy* was not permitted.  In fact, I
couldn't do anything with that ~/.bash_aliases file.  I could
not remove it, and even 'sudo rm' would not get rid of it.

Luckily I work with freebsd, and this sounded a lot like the
"schg" flag in freebsd land.  So I tried:

        ls -lo .bash_aliases

(that's a lowercase-letter-O, not a zero).  This told me:

-rw-r--r--  1 gad  staff  uappnd 21624 Jun 11 14:46 .bash_aliases

I don't recognize 'uappnd', but that is the field which would
list 'schg' under freebsd.  So, I used the 'chflags' command
the same way I would use it under freebsd:

        chflags nouappnd ~/.bash_aliases

After doing this, I was once again able to modify my .bash_aliases
file, which was a good thing...

I have not had time to investigate WHY I ended up with the
uappnd flag on when copying from AFS-land to my local hard
disk, but I thought I would at least mention this in case
someone else runs into it.  At least this way you'll have
a way to get out of the situation when you end up with a
file that you can no longer modify.

For what it's worth, here's the result of doing the 'ls -lo'
on the original file as it sits in AFS-land:

-rw-r--r--  1 drosehn  staff  uappnd,opaque 21624 Jun  7 18:15 
/Users/AFS/drosehn/.bash_aliases

My guess is that there is something in darwin which thinks
those flags are on, but that AFS does not give the same
meaning to "those bits" as HFS+ gives to them.

-- 
Garance Alistair Drosehn            =   gad@eclipse.acs.rpi.edu
Senior Systems Programmer           or  gad@freebsd.org
Rensselaer Polytechnic Institute    or  drosih@rpi.edu