(Illustration by Gaich Muramatsu)
More info: I seem to have been able to remove it now on my laptop but now both narn and lyta have the 'connected, but pending conflicts'. Here is more interesting server logs... 15:25:11 Entering RecovDirResolve 7f000005.123.7ca 15:25:11 RecovDirResolve: RegDirResolution succeeded 15:26:05 GetAttrPlusSHA: Computing SHA 29000005.d5b4.367c, disk.inode=345 15:27:06 PutReintegrateObjects: stale directory fid 0x7f000005.21f.33b8, num 0, max 50 15:27:13 Incomplete host set in COP2. 15:27:14 VGetVnode: memory vnode was snatched away 15:27:14 RS_LockAndFetch: GetFsObj for 29000005.21f.33b8 returned error 102 15:27:14 CheckRetCodes: server 209.234.73.41 returned error 102 15:27:14 PutVolObj: Couldn't find entry 29000005 on lock queue 15:27:14 ViceResolve:Couldnt lock volume 7f000005 at all accessible servers 15:27:15 VGetVnode: memory vnode was snatched away 15:27:15 RS_LockAndFetch: GetFsObj for 29000005.d5b4.367c returned error 102 15:27:15 CheckRetCodes: server 209.234.73.41 returned error 102 15:27:15 PutVolObj: Couldn't find entry 29000005 on lock queue 15:27:15 ViceResolve:Couldnt lock volume 7f000005 at all accessible servers 15:27:16 Entering RecovDirResolve 7f000005.11f.7c9 15:27:16 ComputeCompOps: fid(0x7f000005.11f.7c9) 15:27:16 RS_ShipLogs - returning 0 15:27:16 LockQueue Manager: found entry for volume 0x29000005 15:27:19 Going to spool log entry for phase3 On Wed, Jul 21, 2004 at 03:24:11PM -0500, Troy Benjegerdes wrote: > It's nicely busted.. > > Should I be running the latest CVS? (I am at 6.0.6 release) > > hozer_at_narn Maildir$ ls cur/cur > ls: cur/cur/1055779073.17995_1.kalmia.hozed.org:2,S: Permission denied > hozer_at_narn Maildir$ cd cur/cur > hozer_at_narn cur$ ls > ls: 1055779073.17995_1.kalmia.hozed.org:2,S: Permission denied > 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 194628 > The partition has 18741524 blocks available out of 19134372 > Write-back is disabled > *** There are pending conflicts in this volume *** > > hozer_at_narn cur$ 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 ........ > hozer_at_narn cur$ cfs fl 1055779073.17995_1.kalmia.hozed.org\:2\,S > 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 ........ > VIOCFLUSH: Permission denied > hozer_at_narn cur$ ctokens > > Tokens held by the Cache Manager: > Local username: hozer > > @hozed.org > Coda user id: 1000 > Expiration time: Thu Jul 22 13:35:07 2004 > > hozer_at_narn cur$ clog hozer.admin > username: hozer.admin_at_hozed.org > Password: > hozer_at_narn cur$ cfs fl 1055779073.17995_1.kalmia.hozed.org\:2\,S > 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 ........ > VIOCFLUSH: Permission denied > > > On Wed, Jul 21, 2004 at 04:05:41PM -0400, Jan Harkes wrote: > > 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 > > > > -- > -------------------------------------------------------------------------- > Troy Benjegerdes 'da hozer' hozer_at_hozed.org > > Somone asked my why I work on this free (http://www.fsf.org/philosophy/) > software stuff and not get a real job. Charles Shultz had the best answer: > > "Why do musicians compose symphonies and poets write poems? They do it > because life wouldn't have any meaning for them if they didn't. That's why > I draw cartoons. It's my life." -- Charles Shultz > -- -------------------------------------------------------------------------- Troy Benjegerdes 'da hozer' hozer_at_hozed.org Somone asked my why I work on this free (http://www.fsf.org/philosophy/) software stuff and not get a real job. Charles Shultz had the best answer: "Why do musicians compose symphonies and poets write poems? They do it because life wouldn't have any meaning for them if they didn't. That's why I draw cartoons. It's my life." -- Charles ShultzReceived on 2004-07-21 16:32:30