From a9ccf942bdafbb1a84df186095937e811a390a5d Mon Sep 17 00:00:00 2001 From: Samuel Thibault Date: Sun, 27 Sep 2026 21:02:49 +0200 Subject: ext2 orphan list was implemented --- open_issues/ext2fs_dtime.mdwn | 21 --------------------- 1 file changed, 21 deletions(-) delete mode 100644 open_issues/ext2fs_dtime.mdwn (limited to 'open_issues') diff --git a/open_issues/ext2fs_dtime.mdwn b/open_issues/ext2fs_dtime.mdwn deleted file mode 100644 index 5cb5fb7b..00000000 --- a/open_issues/ext2fs_dtime.mdwn +++ /dev/null @@ -1,21 +0,0 @@ -[[!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. -- cgit v1.3.1