#452 Netatalk 3.0 CNID Inconsistency
I am seeing dbd report CNID errors whenever I use Finder to copy files
from a shared volume to a folder on the same volume. I am using the
Finder's "drag and drop on a folder while holding down the Option key"
method to copy files.
Using dbd to scan the shared volume just prior and after the copy
operation shows the error is introduced immediately after the copy
operation completes. Curiously, no error is reported if I just move
the file into the folder (by not holding down the Option key), nor is
any error reported if I perform the copy operation from the command
line. Somehow Finder appears implicated in this erroneous behavior.
The following dbd error is reported when I use Finder to copy file 'a'
to folder '1' on the shared volume:
Bad CNID in adouble file of '/rpool/guest/1/a'
The shared volume is used for guest access via the 'nobody' user.
Permissions on the ZFS folder is as follows:
drwxr-xr-x+ 2 nobody staff 2 Aug 19 16:29 /rpool/guest/
owner@:rwxp-DaARWcCos:fd-----:allow
group@:r-x---a-RWc--s:fd-----:allow
everyone@:r-x---a-R-c--s:-------:allow
Server information:
SunOS netatalk 5.11 11.0 i86pc i386 i86pc (Solaris 11)
Client information:
Darwin Kernel Version 11.4.0 (OS X 10.7.4)
Build information:
./configure --without-pam --with-init-style=solaris
The client uses copyfile which makes me believe that afpd is possibly copying the metadata EA without adjusting the CNID afterwards.
Fixed in [ff117107526219d5ce89d5ff683eddd414e40293].
Related
Commit: <Commit _id='ff117107526219d5ce89d5ff683eddd414e40293' tree_id='710ac01ddfc9473c73a792f393f2dbf76ed773c8' committed=I{'date': datetime.datetime(2012, 12, 4, 17, 58, 22), 'email': 'franklahm@googlemail.com', 'name': 'Frank Lahm'} authored=I{'date': datetime.datetime(2012, 12, 4, 15, 8, 27), 'email': 'sloowfranklin@gmail.com', 'name': 'Ralph Boehme'} message='Dont copy our metadata EA in copyfile()\n\nApparently Apple is now relying more on the AFP copyfile function\nfor file copies where source and destination are on the same vol.\nThe copying is done by our copyfile() function. It calls into\nour VFS stack where in the end _all_ extended attributes of the\nfile, including our metadata EA, will be copied from source to\ndest.\nThis resulted in an incorrect metadata EA on the destination file,\neg the CNID was still the one of the source file.\nObviously the metadata EA of the destination file must be created\nsuch that all relevant fields are properly assigned.\n\nFixes bug #452.\n' parent_ids=I['1a59f639265e6fc11385a40dcef2a70a53b54954'] child_ids=I['0eae4501cb1d6c61288d2edb2f5e865edba6b0c1'] repo_ids=I[ObjectId('503b705bfd48f843173d5fd3'), ObjectId('5910acbc2cd81052b64b3380'), ObjectId('5e503de0dd85f4654ba114ee'), ObjectId('5e828a7a9d8bdd372301c28f')]>