| 1 |
On Fri, Jul 30, 2010 at 01:34, Andrey Vul <andrey.vul@×××××.com> wrote: |
| 2 |
> On Thu, Jul 29, 2010 at 08:31, Alex Schuster <wonko@×××××××××.org> wrote: |
| 3 |
>> walt writes: |
| 4 |
>> |
| 5 |
>>> On 07/28/2010 01:20 PM, Andrey Vul wrote: |
| 6 |
>>> > Creating files in /tmp, /etc, /lib32, and /var return ENOENT (touch |
| 7 |
>>> > /tmp/foo => strerror(ENOENT)). |
| 8 |
>>> > However, this is done as root and the dirs are marked 755 root:root. |
| 9 |
>> |
| 10 |
>> Are all these directories located on the root file system? |
| 11 |
>> |
| 12 |
>>> Is the sticky bit set on /tmp? |
| 13 |
>>> |
| 14 |
>>> drwxrwxrwt 26 root root 36864 2010-07-29 04:15 tmp/ |
| 15 |
>>> ^ |
| 16 |
>> |
| 17 |
>> Well, it set or not, this would not prevent the creation of files. |
| 18 |
>> |
| 19 |
>> I have no idea what's going on here. I'd force a fsck (touch /forcefsck; |
| 20 |
>> reboot) to make sure it's no file system problem. And what about a live- |
| 21 |
>> cd, does the problem happen then, too? |
| 22 |
>> |
| 23 |
> |
| 24 |
> fsck -f followed by use of USB-SATA bridge seems to work. However, my |
| 25 |
> laptop just died, so I can't really test it on the laptop. |
| 26 |
> |
| 27 |
|
| 28 |
Quoting fsck.jfs : "Incorrect link counts have been detected. Will correct." |
| 29 |
Apparently, some subtle data corruption was invisible by fsck -p but |
| 30 |
noticed by fsck -f. |
| 31 |
A corrupt inode does explain why the directory was somehow 555 in behavior. |
Archives