Hello, 

I'm using a yaffs1 partition on an embedded device where file integrity
is of the utmost importance. 

To manage the files updates atomically, I'm using a sequence of
operation where I create working copy under an alias, update it and
rename it into the name of the original file once the work is completed.


If there is a power loss occurring before the rename, we will retrieve
the original version, if it occurs after that, the new version should be
there. 

It's almost working but it appears that there is a very narrow window
where a powerloss is leaving me with the two versions under the same
name (but different inode) in the same directory. The rename and the
delete of the previous version are 2 distinct operations and if we lose
power between the 2, the problem occurs.  

Is there a way to prevent this? My idea was to alter the intial scanning
to check for non deleted sibling with the same name and keep the one
with the most recent sequence number and scrap the other one. 

Anyone knows if this issue is specific to yaffs1? Would there be the
same issue with yaffs2? 

I've got another issue, which is probably specific to yaffs1. I find
that during the initial scan, if I encounter the header for a deleted
file (parent is deleted dir), that object is destroyed (Line 5806)
despite the fact that more chunks for that file may be encountered later
in the scan...  This leads to these chunks being placed in lost+found.
Has anyone else noticed that ? Is there something I'm doing wrong ?

Regards, 

Matthieu




--
******************************************************************************************
This e-mail (including any attachments) is intended only for the recipient(s)
named above. It may contain confidential or privileged information and should
not be read, copied or otherwise used by any other person. If you are not a
named recipient, please contact the sender by telephone (+44-1454-284800)
and destroy the original message.
Any statement and/or opinion not related to this company's business and
expressed in this message is that of the author and does not necessarily
reflect those of Icera. This company does not take any responsibility
for the views of the author in any matter not related to the
company's objective. 
******************************************************************************************