on Fri, Nov 30, 2001 at 07:48:47PM -0000, Ian Douglas wrote:
/dev/sda5 is indeed a data, rather than an operating system, partition so you are correct in thinking it does contain a lot of my own user files however "df -i /dev/sda5" says:
Filesystem Inodes IUsed IFree IUse% Mounted on /dev/sda5 1026048 9023 1017025 1% /mnt
ok, i just had a look through the fsck source code. libext2fs is generating the error in link.c, function link_proc.
fsck appears to be unable to allocate space for the actual name of the directory ("lost+found") in its parents directory ("/mnt"). It has managed to allocate an inode for the directory.
I'm not entirely sure, but fsck doesn't appear to be able to grow the size of a directory. So if you've filled the directory up to just below it's current "size" (say, 4090), but the kernel hasn't expanded it yet, then from my reading of the fsck source code, fsck isn't able to increase the "size" of that directory, so it fails.
fsck does appear to have the ability to expand the size of the lost+found directory, but only that directory. This seems odd, because libext2fs does have the functions to do this for any directory.
(silly question) Have you tried mkdir /mnt/lost+found? I don't know the effect of doing this, it could cause your computer to spontaneously combust, back up your data first, etc, etc.
If that fails, it might be a case of rolling up sleaves and having a go with debugfs.