Hi Jean-Pierre, I am willing to maintain the system compression plugin and I am planning to make it available on Github, replacing the older non-plugin version. I will add documentation and tests, but I am not sure binaries are worthwhile --- often it can be assumed that people will either build them themselves or get them from packages built by their distribution.
The advantages of having the plugin source code in the NTFS-3G source tree would be that it would seem more official and distributions might be faster to provide packages to end-users since there would be just one "source" package needed for both NTFS-3G and the plugin. The disadvantage is that the plugin could not be updated or released independently, which I understand was a major reason for doing plugins in the first place instead of just adding the code directly to NTFS-3G. I think my current preference is to have the plugin distributed separately, maintained by me, and seeing how many people are interested. It could always be moved into the NTFS-3G source tree in a future release, if desired. Thanks! Eric On Fri, May 06, 2016 at 10:19:24AM +0200, Jean-Pierre André wrote: > Hi Eric, > > Eric Biggers wrote: > > Hi, > > > > Please consider the following patch to simplify how reparse plugin support > > is > > configured. I had suggested this approach before and I do think it is a > > more > > maintainable approach. So here is a concrete patch: > > > > By making symlinks and junctions always handled through internal plugins, > > we can eliminate much duplicate code and #ifdefs. The --disable-plugins > > configuration option is renamed to --disable-external-plugins and now > > only disables *external* (i.e. dynamically loaded) plugins. > > Yes. Please see the current situation as a temporary one and > a way to quickly revert to the old situation if something > goes wrong. So far I have no feedback from platforms which > I cannot support myself (to be precise, only about an error > code not defined on FreeBSD). > > There is a more important decision to make : who maintains > the compression code and how is it distributed. Currently > I have just made available a tarball with a crude makefile > and binaries for a few platforms, but this can only be > temporary. > > I do not consider myself able to provide significant support > in the compression code. Currently my tests only consist > in reading a few Windows DLLs, checking their internal > checksums, and making sure they are seen as files (not > symlinks). I have made no change to your code and the tests > are successful on five CPUs models and three operating > systems. > > So, > > - either you distribute it, and I make references to where > it is available, > - or I create a new directory and add a new configure option > in the ntfs-3g tree so that it is distributed as an option > to ntfs-3g, > - or maybe there could be some intermediate way. > > What is your view about it ? > > Jean-Pierre ------------------------------------------------------------------------------ Find and fix application performance issues faster with Applications Manager Applications Manager provides deep performance insights into multiple tiers of your business applications. It resolves application problems quickly and reduces your MTTR. Get your free trial! https://ad.doubleclick.net/ddm/clk/302982198;130105516;z _______________________________________________ ntfs-3g-devel mailing list ntfs-3g-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/ntfs-3g-devel
