Re: Re: DAR's filename length limitation on Windows

On Thu, 2006-03-16 at 13:52 +0100, Denis Corbin wrote:
> 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 ! :-)

Also, a question: I'm assuming the work you're doing now will change the
dar file format. Have you looked over the file format changes that would
result with my libgpgme patch? What do you think of these?

Wesley


> 
> Waiting for your reactions ! ;-)
> 
> Regards,
> Denis.
> 
> 
> 
-- 
Wesley Leggette <lists-+42/j/[email protected]>

GPG Key:         http://www.kaylix.net/kaylix.asc or http://pgp.mit.edu
GPG Fingerprint: 9B6F 19FB 5296 5E6C 21FE  7614 2A20 5688 F848 9BDD

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.2.1 (GNU/Linux)

iD8DBQBEGfvcKiBWiPhIm90RAkzoAJ40ayYgUojqq1DuUboGKF6dRvIC1gCfcNNJ
qoh3lzNdJ9VeLKKydVSL8IE=
=Pq6N
-----END PGP SIGNATURE-----