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: <project12@banksys.be>.
---------------------------------------------------------------------------------------
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.
(text/plain)