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 ! :-)
> 
> Waiting for your reactions ! ;-)

Oh, I agree completely. The work I did last year is really not that
great and I would not recommend it for actual use. To implement win32
with APR, I would agree with your method.

Unfortunately for windows users, I'm not working on this anymore. Right
now I'm working on python bindings for libdar. But maybe afterwords...

Wesley


> 
> 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)

iD8DBQBEGfitKiBWiPhIm90RApZ8AKCh8uJDT0ZLWMY5GBTgutejukCP8ACff6E0
s9K8kUbAmGmv+QnY2DLZvGU=
=emwz
-----END PGP SIGNATURE-----