bug-fileutils
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

possible new feature: fileutils.so


From: monkeyiq
Subject: possible new feature: fileutils.so
Date: Sat, 02 Dec 2000 02:31:37 +1000

Hi,
    Firstly, sorry if this is not the correct location for this post. I
couldn't find a better place to send it... BTW I am not on any list, so
if any replys could be cc'd to me.

    I am currently toying with the idea of writing (yet another) file
manager for POSIX. To cut a long story short, instead of re inventing
the wheel I was going to try to reuse as much GNU stuff as I can. The
logical starting point is with fileutils. I was thinking of making a
#ifdef option for fileutils that when defined allowed some callbacks to
optionally be set in
struct cp_options
so things like copy_reg() could inform a listener of each block of bytes
that was read/written and atleast which file is being done at that time.
By having this as a #ifdef, the user could comile fileutils without
callbacks to avoid testing the callback functions != null each block.

My plan is to make this a compile time option, and make both the current
targets and also a shared library with much the same functionality in it
too (atleast copy()). This would have only minimal impact to the current
fileutils but also allow me to use them from a GUI and give some decent
feedback as to progress. Error information could (possibly) be captured
from its current filedesc by me, thus reducing the number of callbacks.

I thought that I'd run this by some people before I started to code, as
I would very much like to integrate this patch into the main fileutils
distro. I haven't fully fleashed out the callback API as yet, and am
more seeing if this is seen as an option by those who maintain
fileutils.

Thoughts?

--
--------------------------------------------------------
In this world there are only two tragedies.
One is not getting what one wants,
and the other is getting it.
                -- Oscar Wilde






reply via email to

[Prev in Thread] Current Thread [Next in Thread]