The way this is supposed to work (Posix) is that if a file is open and it gets unlinked, then it disappears from the directory etc but the file is still there until the last handle gets closed. These Posix people thought of some very nasty things to throw at file system writes. The way I designed this to work is that when the file gets unlinked (last link) it gets placed in the "unlinked directory" which is not in the directory tree. It should only be marked for deletion if the file is already closed (or when the file handle is closed). Something is not working properly here :-(. I thought I had tested this... damn. I will look. On Wed, 27 Nov 2002 10:37, Luc Van Oostenryck wrote: > Hi, > > I've found an undiscovered bug in yaffs_unlink(): > The problem arise when CONFIG_YAFFS_DISABLE_BACKGROUND_DELETION > is defined and we unlink() the last/only (hard)link to a file, > but this file is still opened by an application > (the attached program can show this quickly). > > The problem is easy to understand: > unlink(2) call yaffs_unlink() > who call yaffs_Unlink() > who call yaffs_UnlinkWorker() > who call yaffs_UnlinkFile() > who simply delete everything related to this file: > directory entry, object header and data. > > I will look for this tomorrow (European time). > > I will appreciate if you CC any mail related to this to > my stupid email address at work: . --------------------------------------------------------------------------------------- This mailing list is hosted by Toby Churchill open software (www.toby-churchill.org). If mailing list membership is no longer wanted you can remove yourself from the list by sending an email to yaffs-request@toby-churchill.org with the text "unsubscribe" (without the quotes) as the subject.