frequent cache corruption with arla 0.21 on linux 2.2.1

[Nathan Neulinger]

Simon Josefsson wrote:
> 
> Magnus LindstrXm <magnus.lindstrom at radio.kth.se> writes:
> 
> > [lindstrm at hilda weird]$ ls -F
> > [lindstrm at hilda weird]$ ln -s '#test' TEST
> > ln: cannot create symbolic link `TEST' to `#test': No such file or directory
> > [lindstrm at hilda weird]$ ls -F
> > [lindstrm at hilda weird]$ fs flush
> > [lindstrm at hilda weird]$ ls -F
> > ls: TEST: No such file or directory
> > [lindstrm at hilda weird]$ rm TEST
> > rm: TEST: No such file or directory
> > [lindstrm at hilda weird]$ ls -F
> > ls: TEST: No such file or directory
> 
> Uhm, aren't symlinks to names with leading `#':s really mount points
> in AFS?

I believe so. This wasn't the case with my problem.

> You can remove the file with "fs rmm TEST". I don't see any
> inconsistency that would indicate cache corruptions when trying the
> above.

fs rmm didn't work in the cases where I was having trouble.

> 
> The same thing happens with Transarc AFS but with slightly different
> result:
> 
> abba$ ls -F
> abba$ ln -s '#test' TEST
> abba$ ls -F
> ls: TEST: Operation not supported by device
> abba$ fs rmm TEST
> abba$ ls -F
> 
> So it seems that the ln "should" succeed and the errno's returned
> "should" be EOPTNOTSUPP instead.

Yep, and if you name the destination right, it will actually be a mount.
It has the name of the cell and the volume and some other character if
it's a readwrite mount I think.

It's unfortunate though that readlink() doesn't work, as that would make
some find/scan type activities really easy.

-- Nathan