On Sun, Feb 29, 2004 at 08:50:20PM -0800, Steve Simitzis wrote:
> around content before the next crash. ideally, our applications
> shouldn't have to know about the limitations of the underlying
> filesystem. it seems like it would be best if coda could simply handle
> larger directories (and fail gracefully), or handle directories of
> "infinite" size.

"Infinite" size directories will require a lot of changes because we
can't/shouldn't hold all the directory data in (recoverable) memory as
is done now. The changes would probably go all the way to the kernel
module which would need to read a new on-disk directory format.

However, whatever solution we eventually reach, failing gracefully when
the directory entry cannot be created is important either way. So I
started looking at propagating the error instead of asserting. This is
turning out to be an exponentially increasing problem.

The assertion is triggered in one function that adds a new directory
entry, which is called from 4 places (create file/link/directory/symlink).
These are then each called from 6 locations (connected create,
reintegration, repair, and 3 resolution cases). I think I have something
that should work for the connected mode create operations and added
assertions in all the other places. I think that renames can also grow
the directory size, I haven't looked at those yet but it will probably
add another 6 cases.

This is turning out to be a bit more work than I hoped for, sigh.

Jan