RE: [Linux-NTFS-Dev] successful write operation on ntfs volume

[Szakacsits S. <sz...@si...>]

On Thu, 30 Sep 2004, Yuval wrote:

> > But the progress bar is the less important issue. See e.g. 
> > util.c what I'm talking about. The entire util.o is statically 
> > linked with every utility that uses even one function 
> > from it. This bloats the binary sizes.
> > 
> > Solutions:
> > 
> > 1) a new library. Drawbacks: new dependency, nobody wants to do it.
> 
> I hate have having dependencies.

Due to some libntfs-gnomevfs problems, ntfsprogs couldn't be built on
Debian thus testdisk couldn't be built so 100+ Debian based Live, etc
distro couldn't have these tools (easily) to prepare for Linux install
(ntfsresize) or recover (testdisk) the partition table what the 2.6
kernel/parted couple corrupted.

> Moreover, most users use mkntfs, ntfsresize and ntfsclone. I assume a
> few are using ntfswipe. But the rest are mostly useless to the average
> user. I don't see any reason to add a new support library for 3-4
> executables (unlike libntfs which purely handles ntfs)
> 
> > 2) move util.c to libntfs until somebody wants to work on 1) or make 
> >    the application level code compile optionally. 
> 
> In general Anton is right, utils.c does not belong in libntfs.
> But some functions are strongly ntfs related and may be "ported" to
> libntfs. E.g. utils_inode_get_name(), utils_cluster_in_use().
> Moving even some of the function code is useful.
> Btw: this is my favourite option.

Forgot to mention, this has the drawback that the error reporting must be
solved, at least partly (propagating the error messages of the new shared
codes upward, out of the library). 
 
> > 3) leave everything as it is and move the "to be shared" 
> > things to util.c
> 
> As far as I understand, you either mean "leave it as it is now" or
> moving current duplicate code to utils.c.
> If the latter, 

The latter. Code shared by ntfsresize, ntfsclone and ntfsck. 

> may I suggest adding another file so not all of the executable would
> have to use it.

My original plan was that the cluster allocation check and related parts
(most of the duplicated stuff) go to libntfs and the other duplicated code
to utils.c, or also to libntfs with utils.c at the same time.

But having another new file statically linked with some utils, outside of
libntfs is also ok for me. That would be still an improvement and no need
to solve the librarization problems.

	Szaka