On Tue, Jul 20, 2004 at 08:31:09PM -0500, Troy Benjegerdes wrote:
> What exactly does this mean?
> 
> hozer_at_narn cur$ cfs lv .
>   Status of volume 0x7f000005 (2130706437) named "u.hozer.mail"
>   Volume type is ReadWrite
>   Connection State is Connected
>   Minimum quota is 0, maximum quota is 1000000
>   Current blocks used are 194309
>   The partition has 18741952 blocks available out of 19134372
>   Write-back is disabled
>   *** There are pending conflicts in this volume ***

You are right that that is strange. I didn't know that that was
even possible or why it got in that state.

> And I have a file in the formerly conflicted directory that says:
> 
> hozer_at_narn cur$ ls -l cur/1055779073.17995_1.kalmia.hozed.org\:2\,S
> ls: cur/1055779073.17995_1.kalmia.hozed.org:2,S: Permission denied

I've been having some problems myself that sometimes after a repair the
local copy of the file isn't correctly flushed from the cache. So you
end up seeing the old (conflicting) object instead of the correctly
repaired copy on the server. My quick fix it typically to flush the
parent directory (in this case 'cfs fl cur'). This should allow the
client to refetch the correct data from the server along with the
corrected access permissions.

> Also, whenever I run 'repair' it seems to think I don't have tokens, but
> I do. Any ideas?

That is because repair doesn't know about realms and doesn't know how to
check if the user has a valid token for the object we're trying to
repair. I am still split between just removing this message/test or to
try and infer the realm from either the path or cfs listvol data.

Jan