Does it really need unmaintained features?

[azazar]

Undelete File System seems to be broken. And anyway it's unlikely to find someone still using ext2 filesystem. Shouldn't it be removed then?

[azazar]

Many extfs filesystems are obsolete or useless too. Does anyone still using DOS/Windows FDD? Is there any Bad Penguin GNU/Linux? Is HP48 calculator still a thing? Are there any lslR listings left in the wild? Shouldn't all of that be removed too?

[azazar]

mc_adbfs was broken last time I've tried it.

[azazar]

DOS/Windows FDD and Bad Penguin GNU/Linux extfs still not seem to be able to find any use outside of extremely exotic cases.

[zyv]

DOS/Windows FDD

Which one are you referring to?

[azazar]

These two:

[zyv]

I checked it out and it seems that mtools are very much alive. I'd rather see new tests for this VFS. Bad Penguin Linux appears to be defunct long ago indeed. I've opened a PR #5013 to remove it.

[zyv]

Undelete File System seems to be broken.

In how far does your screenshot show that the undelete filesystem is broken?

And anyway it's unlikely to find someone still using ext2 filesystem. Shouldn't it be removed then?

It is supposed to work on ext2/3/4, not only ext2.

[zyv]

It's just an interface to what the standard e2fsprogs library provides, but it seems that I was wrong about support for ext3/ext4:

https://e2fsprogs.sourceforge.net/ext2.html

Unfortunately, I can't seem to get it to work either, also for ext2.

I wonder if we should indeed just remove it instead of debugging and/or trying to fix it. It's of limited use for ext2 even if we get it to work again.

What do you think, @mc-worker ?

[azazar]

Looks like it's using libext2fs. It's doesn't use e2fsprogs.

[egmontkob]

What was the conclusion, is this an ext2-only thing or ext2-3-4?

[zyv]

What was the conclusion, is this an ext2-only thing or ext2-3-4?

Well, in the end, it seems that I was both right and wrong:

I was right in a sense that from the purely technical standpoint the code as such might run on ext3/ext4 due to their backwards compatibility provisions. I was wrong in a sense that even if it would run, the results will be utterly useless.

If you have a look at the code, the idea was to scan the ext2 inode list and look for entries with i_dtime set (marker that the inode has been deleted). The list of such inodes can be displayed and the contents can be copied to a different filesystem.

This used to work indeed in the old days, but relied on the relative simplicity of the ext2 on-disk layout and inner workings. Specifically, back then the metadata like file size and block addresses remained available.

Modern file systems introduced lots of new features like journaling, but most importantly block pointers and file size are now removed from deleted inode table entries, and the blocks are marked as free, so will likely be quickly overwritten.

Thus, even if you get a list of deleted inodes, this doesn't really give you anything at all, unfortunately. You need to find out the old file size, and somehow reconnect the chain of data blocks that used to belong to this file. Our VFS obviously implements nothing like this.

A number of projects tried to adapt to the new extended file systems, the latest to my knowledge being ext4magic. It is, however, unmaintained since at least 10 years and according to the author doesn't work with modern ext4 systems anymore.

So, really, the only viable option is probably carving tools like testdisk or specialized recovery software... but in any case, I wasn't even able to get the old code to work with ext2.

I don't know why it doesn't work anymore, but I don't feel like putting the effort into fixing it for ext2 is worth it. First, I seriously doubt there are many active ext2 users with demand for undeletion, and second, they can use ext2fs tools, which are still supposed to work for ext2.

Having all that said, I now tend to think that zapping the code is the best idea.

[egmontkob]

Thanks for the explanation! I fully agree with your conclusion.