> Actually it is probably the parent directory. When your client tries to > access the file, the server has to grab the parent directory to check > the ACL. But if the parent is inconsistent it returns EINCONS and the > client shows the file as being inconsistent.
It's odd though that there are other files in the directory that are
consistent.
> The problem is that the callback that was sent to force directory
> revalidation was lost or ignored because the directory was dirty, or
> something has a reference to it and we can't turn it into a dangling
> symlink.
OK, that would make sense.
> I'm not yet sure how to fix this, I guess I could ignore the
> inconsistency when checking the ACL, if there happens to be an
> (unlikely) difference between the servers, some will perform the
> operation and others might return permission denied. But since setacl
> is fairly infrequent the servers should agree most of the time.
Yes, in our case, acl's only change in the one-time setup phase.
> cfs fl on the parent directory should make the real conflict visible, as
> long as there are no processes that have an active reference and are
> keeping it pinned as a directory in the kernel.
Does this go for all clients? Doesn't seem like it should. Your
suggestion sounded great, but isn't working. Here's a little
transcript:
# ls -l remupd/isched.ppi
lrwxr-xr-x 1 admin 65534 36 Jul 12 13:09
remupd/isched.ppi -> @[EMAIL PROTECTED]
# cfs fl remupd
DANGER: these files will be lost, if disconnected
Do you really want to do this? [n] y
Fools rush in where angels fear to tread ........
# cfs fl .
DANGER: these files will be lost, if disconnected
Do you really want to do this? [n] y
Fools rush in where angels fear to tread ........
# ls -l remupd/isched.ppi
lrwxr-xr-x 1 admin 65534 36 Jul 12 13:09
remupd/isched.ppi -> @[EMAIL PROTECTED]
# ls -l remupd/data.tag
-rw-rw-r-- 1 admin 65534 110 Jun 8 2004 remupd/data.tag
# lsof |grep remupd
(no output)
# cfs br remupd/isched.ppi
remupd/isched.ppi isn't inconsistent
Any new thoughts? I tried this process on the client that's writing
the files as well as on a client that just reads them. Same effect.
--
Patrick Walsh
eSoft Incorporated
303.444.1600 x3350
http://www.esoft.com/
signature.asc
Description: This is a digitally signed message part
