Any plans for ext writing?

[Levi--G]

Hi,

Just wondering if there are any plans to implement ext writing or if there is a technological reason why it wouldn't be possible?

Thanks!

[Olof-Lagerkvist]

It would be very useful, I agree. It would mean a lot of work though.

So far I have managed to workaround this by implementing interfaces with methods that can expose physical sectors where a file is allocated and that way do minor modifications to existing files directly in allocation clusters. But it is far from ideal, of course. Full write support for more file system implementations would be much better.

[Levi--G]

So far I have managed to workaround this by implementing interfaces with methods that can expose physical sectors where a file is allocated and that way do minor modifications to existing files directly in allocation clusters

Are these in the project or did you add them externally? I didn't find them. :)

I have taken a look at https://github.com/nickdu088/SharpExt4 and lwext4 before, but i don't like the windows and cpphost dependency. So a working discutils solution would be very much appreciated! 😄 I realise that takes a lot of effort, but it doesn't need to be fully featured to already be very useful. Just file allocation/creation would cover 50% of use i think.

A few days ago i was looking to make it myself but i got stuck not fully understanding how discutils works and why certain design choices were made so i don't think i can be of much use sadly.

[Olof-Lagerkvist]

So far I have managed to workaround this by implementing interfaces with methods that can expose physical sectors where a file is allocated and that way do minor modifications to existing files directly in allocation clusters

Are these in the project or did you add them externally? I didn't find them. :)

There is an interface IClusterBasedFileSystem that has a method PathToClusters that you can use to find allocation clusters for a file. That way, you could edit existing data directly in the allocated clusters.

I have taken a look at https://github.com/nickdu088/SharpExt4 and lwext4 before, but i don't like the windows and cpphost dependency. So a working discutils solution would be very much appreciated! 😄

I agree, DiscUtils is designed from start to be entirely .NET with no native or OS specific dependencies. There are a few recent exceptions though mainly for some compression algorithms that bring with them some native libraries. At least they are available for most commonly used OS platforms. But ideally, we should switch to using .NET alternatives there as well.

I realise that takes a lot of effort, but it doesn't need to be fully featured to already be very useful. Just file allocation/creation would cover 50% of use i think.

Allocation and creation is what needs the most work to complete. Editing existing files is a bit easier to implement.

A few days ago i was looking to make it myself but i got stuck not fully understanding how discutils works and why certain design choices were made so i don't think i can be of much use sadly.

Yes, it is a really complex code base these days that often take a lot of time and effort to get familiar with. Lots of interfaces and base classes that are each important for the whole picture.

[Olof-Lagerkvist]

Sorry I forgot, but there is an even easier way nowadays with IAllocationExtentsFileSystem.PathToExtents which is implemented by more file systems than only those implementing IClusterBasedFileSystem.

[Levi--G]

Sorry I forgot, but there is an even easier way nowadays with IAllocationExtentsFileSystem.PathToExtents which is implemented by more file systems than only those implementing IClusterBasedFileSystem.

Directly editing clusters/extents might be slightly too dangerous for my usage, I get a feeling i'll spend days wondering why my image is corrupt 😄 Thanks though!

[Olof-Lagerkvist]

This is a useful feature idea and something that would fit well within DiscUtils, but full write support for ext filesystems would be a substantial new development effort rather than a specific actionable issue.

As DiscUtils is getting more users, I would like to keep the issue tracker focused on concrete bugs and reasonably scoped actionable work. Broader feature ideas, architectural discussions and potential future capabilities are better suited for GitHub Discussions.

I am therefore converting this issue to a discussion so that the idea and the technical conversation can remain open without implying that implementation is currently planned or scheduled.