On Fri, Oct 15, 2021 at 12:43:33PM -0700, Avi Deitcher wrote: > Thanks, Ted, I will try yours and step through it to figure out what is off. > > You ask a fair question: other than madness, why would someone want to > recreate the exact algorithm? > > I have had a number of cases where I have needed to manipulate disks, > filesystems, partition tables, etc. from within a non-C-source > program. The options have been: fork/exec to some external program; > run a VM where I can mount the fs and manipulate content as needed. > Those both work, but have had issues in various environments. > > I made the mistake of saying, "well, all of this is just manipulating > bytes on a disk image or block device; how hard could it be?" :-) > So understanding the algorithm actually becomes important. I think once you take a look at all of the "byte manipulation" that is needed for any kind of non-trivial file system operation, you're probably better off trying to figure out how to link the library in. > I probably could link the library in if I am working on languages that > support it (go, rust), but not all do, and there are reasons that is > more difficult for the target use case. Have you looked at SWIG? SWIG suppotrs a *lot* of lanaguages, including Tcl, Python, Perl, Guile, Java, Ruby, Mzscheme, PHP, OCaml, C#, Lua, R, Octave, Go, D, Javascript, Scilab, etc. If you end up writing the equivalent of libext2fs for one language, it's really not going to help you all that much for another language. I also note you've not really been specific about "the target use case". Is that something you'd be willing to say more about? In any case, if you're interested in implementing SWIG bindings for libext2fs, that is certainly something we could discuss integrating into e2fsprogs, so that other people could also benefit from that work. Let me know if you're interested! - Ted
