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