[Haskell] Announcing harchive-0.2: Backup and restore software in Haskell.
Announcing release 0.2 of "harchive", a program for backing up and restoring data. I've included a brief feature list below. The code is available in darcs at: http://www.davidb.org/darcs/harchive/ The package is available from hackage at: http://hackage.haskell.org/cgi-bin/hackage-scripts/package/harchive-0.2 This release fixes some serious problems with the 0.1 release. No significant features have been implemented, but the code can now be compiled with '-O' without causing segfaults. Dave Brown -- Harchive version 0.2: - Several changes that change the storage format: - Changed protocol and storage format a bit to not encode lengths with hashes. - Record attributes of root directory. - Fix some problems with multiple threads on the SQL binding. There is still a problem, but by only using one OS thread, it doesn't appear now. Multiple simultaneous clients appear to work. ___ Haskell mailing list Haskell@haskell.org http://www.haskell.org/mailman/listinfo/haskell
[Haskell] Announcing harchive: Backup and restore software in Haskell.
Announcing release 0.1 of "harchive", a program for backing up and
restoring data. I've included a brief feature list below. The code
is available in darcs at:
http://www.davidb.org/darcs/harchive/
The connection isn't all that fast, so if it gets too busy, I'll move
it somewhere else.
This software is in a very early stage, but is at the point where
others may be interested in looking at it. It does demonstrate that
Haskell (at least GHC) is indeed useful for this kind of low-level
seeming task.
Thanks,
David Brown
Harchive version 0.1.
- Implemented, with support for the following.
- Client/server model. The backup is stored in a file pool with
the hpool program. The hfile program can access this pool over
tcp (no authentication or encryption, so be careful).
- Stores data from multiple backups and multiple machines in a
content addressible store. Duplicated data even on separate
machines will not take additional space. Collisions can be made
arbitrarily improbable by choice of hash function size (not
easily changeable, in the current code, though).
- Pool manager uses Sqlite3 specific capabilities to get efficient
storage of the pool index. Sqlite3 is a custom binding to
Sqlite3 to take advantage of these capabilities.
- Uses openssl's sha1 library. Wouldn't be difficult to use a
different library (there are license issues with openssl).
Generally the program's performance is bound by the speed of
hashing and/or the speed of data compression.
- Uses Duncan Coutts' zlib library to get good zlib speed.
- Linux dependent. Uses the output of '/sbin/blkid' to map
devices to UUIDs of the filesystems to get persistent, and
unique identifiers for each filesystem.
- Has a primitive status display ('-v') during backup.
- Able to backup and restore directories/filesystems. Restore
semantics are as accurate as I can get them without extra
strange semantics.
- Multithreaded backup. Allows backup to run at high speed, even
while waiting for cache responses from the server. Does not
need to be built with '-threaded'.
- Restore is reasonably simple. It tends to get tested less, so
it is beneficial to move complexity to the backup side.
___
Haskell mailing list
Haskell@haskell.org
http://www.haskell.org/mailman/listinfo/haskell
Re: [Haskell] Laziness and the IO Monad (randomness)
Dave Tapley wrote: > This code show a trivial case where randomness (and hence the IO > monad) is not used and the first 10 elements of the produced list > are printed: You don't need the IO monad to achieve pseudy-randomness. Why not use 'randoms' from System.Random (or 'randomRs' for a range). take 10 $ (randomRs (1,6) (mkStdGen 1)) :: [Int] You can use the IO monad to get a randomly seeded generator from the outside, but once seeded, just use the list. gen <- newStdGen take 10 $ (randomRs (1,6) gen) :: [Int] Dave ___ Haskell mailing list Haskell@haskell.org http://www.haskell.org/mailman/listinfo/haskell
Re: [Haskell] Reading a directory tree
On Mon, Jun 28, 2004 at 11:08:38AM -0400, Isaac Jones wrote: > My basic requirement is that they should be functions useful for > system administration. > > We've sucked in some functions in from GHC and from Cabal[1]. It would > be nice if we could just have a dumping ground for related functions > that people have written. Functions that recursively iterate directories should _never_ follow symlinks as if they were directories (possibly optionally). It is rarely what is wanted. To fix this, use getSymbolicLinkStatus instead of getFileStatus. For directory iteration, the called function will usually need to know at least some information about each file. Since you have to get a FileStatus for each file anyway, you might as well pass it to each child. Also, it is important to handle errors that happen during iteration. If you try statting, or reading something incorrect, you can cause exceptions, which will need to be handled. SlurpDirectory has some useful code (in darcs), but is fairly specific to darcs. It is actually fairly challenging to come up with useful directory iteration that is generic. What about filtering? Dave Brown ___ Haskell mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/haskell
