Re: [Yaffs] Dual '.' entry in directory

Top Page
Attachments:
Message as email
+ (text/plain)
Delete this message
Reply to this message
Author: Henrik Grindal Bakken
Date:  
To: yaffs
Subject: Re: [Yaffs] Dual '.' entry in directory
Henrik Grindal Bakken <> writes:

> Hi. I have a device running on a Texas Instruments DaVinci chip
> with a NAND flash upon which I have a yaffs2 file system.
>
> It's a 2.6.35 kernel with yaffs2 code from ca half a year ago.


Bringing this one up again...

We also have another device, running on a PowerPC processor with
Linux-3.0.4 and same yaffs2 as the one above.

I have a directory on the flash (named "image1") originally containing
lots of files, including one file named "call_log.db", which is
written to fairly often.

On a software upgrade, we delete the "image1" directory, recreate it,
and extract the new software into it. We also copy the call_log.db
from the other image (image2).

Now, in some cases this copy process (and also the rm -rf, but this we
ignore) fails, claiming it's "out of memory".

Looking at the supposedly empty directory, I see this:

[orion-ep22:~] $ rm -rf /mnt/base/image1/
rm: cannot remove `/mnt/base/image1': Directory not empty
[orion-ep22:~] $ ls -l /mnt/base/image1/
total 94
-rw-r--r-- 1 root root 5560 Jan 2 16:08 call_log.db
-rw-r--r-- 1 root root 5560 Jan 2 16:08 call_log.db
-rw-r--r-- 1 root root 5560 Jan 2 16:08 call_log.db
-rw-r--r-- 1 root root 5560 Jan 2 16:08 call_log.db
-rw-r--r-- 1 root root 5560 Jan 2 16:08 call_log.db
-rw-r--r-- 1 root root 5560 Jan 2 16:08 call_log.db
-rw-r--r-- 1 root root 5560 Jan 2 16:08 call_log.db
-rw-r--r-- 1 root root 5560 Jan 2 16:08 call_log.db
-rw-r--r-- 1 root root 5560 Jan 2 16:08 call_log.db
-rw-r--r-- 1 root root 5560 Jan 2 16:08 call_log.db
-rw-r--r-- 1 root root 5560 Jan 2 16:08 call_log.db
-rw-r--r-- 1 root root 5560 Jan 2 16:08 call_log.db
-rw-r--r-- 1 root root 5560 Jan 2 16:08 call_log.db
-rw-r--r-- 1 root root 5560 Jan 2 16:08 call_log.db
-rw-r--r-- 1 root root 5560 Jan 2 16:08 call_log.db
-rw-r--r-- 1 root root 5560 Jan 2 16:08 call_log.db
-rw-r--r-- 1 root root 5560 Jan 2 16:08 call_log.db

I can delete the files, one at a time, it seems:
[orion-ep22:~] $ ls -l /mnt/base/image1/ | wc -l
18
[orion-ep22:~] $ rm /mnt/base/image1/call_log.db
[orion-ep22:~] $ ls -l /mnt/base/image1/ | wc -l
ls: cannot access /mnt/base/image1/call_log.db: No such file or directory
ls: cannot access /mnt/base/image1/call_log.db: No such file or directory
ls: cannot access /mnt/base/image1/call_log.db: No such file or directory
ls: cannot access /mnt/base/image1/call_log.db: No such file or directory
ls: cannot access /mnt/base/image1/call_log.db: No such file or directory
ls: cannot access /mnt/base/image1/call_log.db: No such file or directory
ls: cannot access /mnt/base/image1/call_log.db: No such file or directory
ls: cannot access /mnt/base/image1/call_log.db: No such file or directory
ls: cannot access /mnt/base/image1/call_log.db: No such file or directory
ls: cannot access /mnt/base/image1/call_log.db: No such file or directory
ls: cannot access /mnt/base/image1/call_log.db: No such file or directory
ls: cannot access /mnt/base/image1/call_log.db: No such file or directory
ls: cannot access /mnt/base/image1/call_log.db: No such file or directory
ls: cannot access /mnt/base/image1/call_log.db: No such file or directory
ls: cannot access /mnt/base/image1/call_log.db: No such file or directory
ls: cannot access /mnt/base/image1/call_log.db: No such file or directory
17

However, this left the rest of the files in a weird state, to say the
least:
[orion-ep22:~] $ ls -l /mnt/base/image1/       
ls: cannot access /mnt/base/image1/call_log.db: No such file or directory
ls: cannot access /mnt/base/image1/call_log.db: No such file or directory
ls: cannot access /mnt/base/image1/call_log.db: No such file or directory
ls: cannot access /mnt/base/image1/call_log.db: No such file or directory
ls: cannot access /mnt/base/image1/call_log.db: No such file or directory
ls: cannot access /mnt/base/image1/call_log.db: No such file or directory
ls: cannot access /mnt/base/image1/call_log.db: No such file or directory
ls: cannot access /mnt/base/image1/call_log.db: No such file or directory
ls: cannot access /mnt/base/image1/call_log.db: No such file or directory
ls: cannot access /mnt/base/image1/call_log.db: No such file or directory
ls: cannot access /mnt/base/image1/call_log.db: No such file or directory
ls: cannot access /mnt/base/image1/call_log.db: No such file or directory
ls: cannot access /mnt/base/image1/call_log.db: No such file or directory
ls: cannot access /mnt/base/image1/call_log.db: No such file or directory
ls: cannot access /mnt/base/image1/call_log.db: No such file or directory
ls: cannot access /mnt/base/image1/call_log.db: No such file or directory
total 0
-????????? ? ? ? ?            ? call_log.db
-????????? ? ? ? ?            ? call_log.db
-????????? ? ? ? ?            ? call_log.db
-????????? ? ? ? ?            ? call_log.db
-????????? ? ? ? ?            ? call_log.db
-????????? ? ? ? ?            ? call_log.db
-????????? ? ? ? ?            ? call_log.db
-????????? ? ? ? ?            ? call_log.db
-????????? ? ? ? ?            ? call_log.db
-????????? ? ? ? ?            ? call_log.db
-????????? ? ? ? ?            ? call_log.db
-????????? ? ? ? ?            ? call_log.db
-????????? ? ? ? ?            ? call_log.db
-????????? ? ? ? ?            ? call_log.db
-????????? ? ? ? ?            ? call_log.db
-????????? ? ? ? ?            ? call_log.db


And rm on the file now fails. However, if I delete the _directory_,
it works. One file less.

[orion-ep22:~] $ rm -rf /mnt/base/image1/
rm: cannot remove `/mnt/base/image1': Directory not empty
[orion-ep22:~] $ ls -l /mnt/base/image1/|wc -l
16
[orion-ep22:~] $ rm -rf /mnt/base/image1/
rm: cannot remove `/mnt/base/image1': Directory not empty
[orion-ep22:~] $ ls -l /mnt/base/image1/|wc -l
15

When I run the rm -rf stunt, the size and contents of the file(s)
change. They're always displayed as the same size, but that size will
change if I remove one of the files.

I'm a bit lost... Does anyone have any ideas as to how to attack
this?


--
Henrik Grindal Bakken <>
PGP ID: 8D436E52
Fingerprint: 131D 9590 F0CF 47EF 7963 02AF 9236 D25A 8D43 6E52