summaryrefslogtreecommitdiff
path: root/open_issues/ext2fs_dtime.mdwn
blob: 5cb5fb7bc7c827c4bd269cfe84037f74da8e7de7 (plain)
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
[[!meta copyright="Copyright © 2014 Free Software Foundation, Inc."]]

[[!meta license="""[[!toggle id="license" text="GFDL 1.2+"]][[!toggleable
id="license" text="Permission is granted to copy, distribute and/or modify this
document under the terms of the GNU Free Documentation License, Version 1.2 or
any later version published by the Free Software Foundation; with no Invariant
Sections, no Front-Cover Texts, and no Back-Cover Texts.  A copy of the license
is included in the section entitled [[GNU Free Documentation
License|/fdl]]."]]"""]]

[[!tag open_issue_hurd]]

    /dev/hd0s1: Deleted inode 95849 has zero dtime.  FIXED.

This is actually sorta benign.  What typically happens is that one upgrades e.g.
a library, and there are still some processes using it (e.g. because it's libc).
The library file is thus kept on the filesystem, so as to be able to load parts
of it on demand.  The file is thus marked as deleted, but the deletion hasn't
been effective yet, thus dtime being zero. e2fsck notices this and finishes
deleting the file.  To really fix this, we would probably have to really unmount
the filesystem.