Is this project still being maintained?

[nikitalita]

There are several open PRs that address open issues, and there hasn’t been an update in over a year. There are several downstream projects that take this in as a dependency. Do you intend to maintain this going forward or should this project be forked?

[LTRData]

I have considered this project as practically abandoned for a while now and started working on a fork where I have fixed lots of bugs, particularly regarding ntfs and ext, but also many other small things in various places, like better compatibility with non-Windows platforms and generally better performance by tweaking memory usage and GC pressure. I have also added async/await and Span<byte> support throughout most I/O code paths.

There are still things left to fix and adjust, but since my fork is used by a few actively developed projects things tend to be investigated and fixed pretty quickly.

My fork: https://github.com/LTRData/DiscUtils

[LordMike]

We could add you as a member, @LTRData - then packages could be pushed on the official nuget feed.

[LTRData]

This repo and my fork are not exactly interchangeable because of breaking changes in interfaces, method return types and some other things. Typically not that difficult to adjust to when consuming the libraries, but at least for some more time I think it is useful to keep them separate.

[mf-RDP]

Great Thanks to LTRData for picking up with this again. However, now exist two major forks of this project, which is somehow an unhappy situation. LordMike, what about considering integrating with LTRData again? Although, considering contributions withing last 18 months, this would probably mean to make the LTRData fork the lead for now.

[LordMike]

Eh - then on the other hand, if those changes are beneficial, it could be wrapped up in a major version bump.

[mf-RDP]

Sure. I did not want to discomfort anyone. However, as this is really a good project and for sure used by many, a dev using it will now need to choose a) take the original one, but miss out fixes and it will probably be unmaintained once in a while or b) take the newer one, "but it's just a fork". That's sad. Also, I guess it's attracting less new contributors this way.

[LTRData]

Sure. I did not want to discomfort anyone. However, as this is really a good project and for sure used by many, a dev using it will now need to choose a) take the original one, but miss out fixes and it will probably be unmaintained once in a while or b) take the newer one, "but it's just a fork". That's sad. Also, I guess it's attracting less new contributors this way.

But this is also originally a fork. Similar to this situation has happened a few times before in the history of DiscUtils. It is not ideal of course, but considering the age of the code base it is not particularly surprising either. Things like this happen. It is still a very popular library.

[zivillian]

I'm not saying I would do that, but what are the criteria for stepping in to the project?

I'd like to keep the code "compatible", but also like to move this project forward.

[LTRData]

I'm not saying I would do that, but what are the criteria for stepping in to the project?

I'd like to keep the code "compatible", but also like to move this project forward.

My goal for many years was to keep compatibility, but the projects I worked on that used this library got some requirements that made it impossible in practice. Both about exposing some internal structures for analyzing file system and image format internals and demands for better performance and more efficient memory management. It still think that it is useful to aim at "as close to compatible as possible", in a way that should make it fairly easy to migrate existing consuming projects. It still requires some care though, particularly in cases where return types have changed and similar.

[zivillian]

@LTRData Sure, the framework has moved on and there are many places in the codebase which need to be brought into our century.

But let's keep this issue focused on:

• What are the requirements for a maintainer?
• What needs to be done?
• What should not happen?
• Anything else?

@qmfrederik & @LordMike: do you have any thoughts?

[LTRData]

Those are good questions and it reminds me about the idea I had for a while about adding a list of things currently not supported but various parts of the library. Such a list would make things a lot easier to discuss.

[mf-RDP]

My opinion:

• Maintainer should be willing and be able to support this in a relatively long term, at least generally speaking
• New features or new FS support is not so important. I think the container formats and the FS formats supported are very long living standards and DiscUtils is great already in terms what's supported.
• Important are bug fixes. I discovered a few minor issues and fixed myself (NTFS related, unfortunately I cannot find out currently what it was).
• What should not happen: Introducing bugs. For this project, reliability is more important than new features or max performance, my opinion.

[LTRData]

• New features or new FS support is not so important. I think the container formats and the FS formats supported are very long living standards and DiscUtils is great already in terms what's supported.

There have been new features added to some file systems over the years that have not been implemented in DiscUtils and that sometimes cause unexpected behavior. For example the new NTFS WofCompressedData streams cause system files in some images to appear empty when using DiscUtils. Adding support for things like that is probably not very difficult though.

[LordMike]

What’s interesting with this project is that it seems to be in use by more technical users than other open source projects. I’ve noticed that a lot of the issues that popped up, would more often than not be followed up by a PR.

My issue is that I don’t have the time and energy to look at the pr’s, sometimes large, mostly for filesystems I have no experience with (or ability to test). Added to that, I also see the need for the library to be stable - so any change should be followed up with at least some tests or manual testing to test if stuff still works.

So the bar of entry is high.

For starters. Anyone helping could simply look at the prs, and evaluate those - maybe accepting them. I also hope the code contributor is in good faith and will do their own best to ensure compatibility. I’m sure GitHub actions could also be leveraged more to do stuff like test coverage, code style enforcement or public api surface stability - and thereby auto refuse new code that breaks or worsens things.

I do not imagine a maintainer would need to take on responsibility to debug and fix “every” issue. Users should be aware that this library is huge, and some effort on the users end is required.

So any help is appreciated. :)

I don’t think I’ve made any thoughts on sketching a direction for the project. Like, should its api surface be updated (changed), must it be stable at all costs, must all new code have tests, .. so it’s mostly a Wild West currently.

[LordMike]

GitHub packages could also be set up with packages for (some) branches, allowing those experiencing an issue to test out the fix(es) before they’re merged into the main branch.

This could also help offload work in by letting the issue author / other interested parties easily test the fix(es) in their systems without having to revert the main packages.

[zivillian]

may someone pin the issue to make it clear what expectations can be placed on new issues?