public inbox for ecos-devel@sourceware.org
 help / color / mirror / Atom feed
* FATFS bug
@ 2008-04-03 11:22 Andrew Lunn
  0 siblings, 0 replies; only message in thread
From: Andrew Lunn @ 2008-04-03 11:22 UTC (permalink / raw)
  To: eCos Devel

Hi Folks

While testing the recent contribution for readdir d_type, i found a
bug in fatfs. Enabling assert brings this to light when running the
fatfs1 test case. Without asserts it dereferences a null pointer,
which on synth in gdb causes a segmentation fault.

The problem sequence goes like:

mkdir("noonoo");
chdir("noonoo");
chdir("..");
rmdir("noonoo");

The problem is with the chdir(".."), which later causes the rmdir to
explode.

The fatfs does not correctly implement the concept of .. . Each
directory does have . and .. directories inodes, but .. does not seem
to link back correctly to the parent directory inode. Doing a
chdir("..") takes you into the .. inode, when it should take you up a
level to the parent. chdir("..") also increments the reference count
on the ".." inode, not the inode of the parent directory. This is why
the rmdir("noonoo") fails, the inode for "noonoo/.." reference count
is not zero.

This problem was not spotted before because until the last patch we
actually leaked the . and .. inodes when a directory was removed.  Now
we try to clean them up get run into this problem.

Does anybody have time to look at this?

     Thanks
        Andrew

^ permalink raw reply	[flat|nested] only message in thread

only message in thread, other threads:[~2008-04-03 11:22 UTC | newest]

Thread overview: (only message) (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2008-04-03 11:22 FATFS bug Andrew Lunn

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).