Re: DAR's filename length limitation on Windows

Wesley Leggette wrote:
> On Thu, 2006-03-16 at 00:01 +0900, Masaru Tsuchiyama wrote:
> 

[...]

>>But I think there are two ways to do it.
>>One is to make dar's own platform abstract layer.
>>The other is to use a existing library, for example
>>Apache Portable Runtime(APR).
>>
>>The first way is to take much time.
>>The second way is to solve a licence problem if the library's
>>licence is not GPL or LGPL.
> 
> 
> Libdar is GPL, so that's not a problem. But APR is a good idea. When I
> worked on converting libdar to win32, I didn't know about APR. Using it
> would make things a LOT easier.
> 
> 

Hello,

that's interesting, but briefly seen the API, this seems to  be a 
consequent work! And I just wonder what would be the impact on 
performances ...

To my point of view, the correct approach in using APR is to define a 
namespace (let's take libdar_os) in which all necessary symbols to make 
becoming portable (functions, datastructures, macro, etc. ) are defined.

A specific module (I mean a file and its header) would implement theses 
system related symbols with APR, another module should also implement 
theses symbols with native system calls. OK, it may be better to have 
all in the same file this way:


	#ifdef LIBDAR_OS_APR
            <symbol implementation>
         #else
           #ifdef LIBDAR_OS_UNIX
            <symbol implementation>
           #else
             # error "unknown system"
           #endif
         #endif
	

At compilation time either the first of the second set of symbol 
implementations would be compiled and linked into libdar, adding a new 
dimensions in the already existing different flavors of libdar with at 
least two different values "Unix Native" and "APR" --- we can imagine 
for the future other values for other systems not covered by APR nor 
Unix systems.

This way, inside libdar and inside dar's command line tools (dar, 
dar_xform, ...) in place of calling the read() system call we would have 
to call libdar_os::read() and for example in place of

    struct stat

we would have

    <stuct/class/...> libdar_os::stat


The important idea is to minimize the impact on the existing dar's code, 
and if the impact cannot be avoided the idea is to reduce the impact at 
the smallest possible scale (we cannot afford to completely rewrite 
libdar+dar for this portability operation). Replacing a "struct stat" by 
a "class stat" is OK, even possible is to have a lstat() method of this 
class that replaces the lstat() system call --- with less or different 
arguments type --- The impact brought by this type of modification are 
local to each function using the stat() system call, there is no need to 
rewrite the header of theses dar's function for example, nor to expect a 
change in the service they render to the rest of the application.

It would be great idealy to have the libdar_os API providing an API very 
similar to the one provided by Unixes, actually used by dar.

Also, another advantage in doing this way is that does not block dar's 
development, I am actually working on the way hard links are managed in 
dar, this is a consistant change in libdar, [this would then let dar 
save hard links of pipes and symlinks and more important to have the 
archive merging become more powerful (when a file is present in both 
archives to merge actually dar always takes the one of the first 
archive, I hope to be able to let the user choose between different 
policies, like keeping the most recent, the less recent, the one of the 
first archive, and so on)]. Unfortunately, this will already take me my 
time for several weeks, so if someone is willing doing this work now it 
stays possible and is welcome ! :-)

Waiting for your reactions ! ;-)

Regards,
Denis.

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.6 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFEGV+VpC5CI8gYGlIRAlrGAJ0XSLKSMfZRdUC5kwVaHVHD75Cw0QCfce4u
n2D+NUXSEyIv1JxNBq7JwuE=
=5f7P
-----END PGP SIGNATURE-----