head	1.4;
access;
symbols;
locks; strict;
comment	@# @;


1.4
date	97.01.08.03.21.02;	author tromey;	state Exp;
branches;
next	1.3;

1.3
date	96.11.26.18.09.24;	author tromey;	state Exp;
branches;
next	1.2;

1.2
date	96.11.24.07.35.57;	author tromey;	state Exp;
branches;
next	1.1;

1.1
date	96.09.14.23.46.52;	author tromey;	state Exp;
branches;
next	;


desc
@@


1.4
log
@various fixes
@
text
@-*- indented-text -*-

Priorities:

-- release 2.4.50

** add a note about setting ROOT during testing to avoid spurious
   failures on some systems.

** Look into merging headers with Franc,ois

** write test for bug fixed by Han Holl

** add --backup flag, like tar

* Write to cpio.texi maintainer with suggestions:
  * Need to handle pax
  * merge all 'invoking cpio' sub-nodes into one node

* Finish pax code
  * -c might need some work where directories are concerned (?)
  * -d needs work where directories are concerned
  * -n is completely unimplemented.
  * preserve_mode_flag is unimplemented

  Question: do pax patterns really not act like cpio patterns?  That
  is, they do strict "fnmatch" style matching, not "ignore '/'
  matching".  Test.

* Add "delete after copying" flag to pax.  Then you can batch rename
  files using: pax -r -w -l -<deleteflag> ...
  [ this is probably a bad idea ]

* There is a request for a verify-after-write flag, a la tar.
* There is a request for a --what-if option.  This would let you see
  which files would actually be extracted.  Code for this exists
  already.

* how to handle fact that corrupt archives are generated if files
  change as cpio runs?  one idea is to just punt, but provide a
  --volatile (?) flag that first reads the entire file into memory
  before dumping.  Obviously this could fail if the file is
  excessively large.

* Probably should always dump directories first, even in cpio format
  (for pax?  Or cpio too?)  We could get around current cpio
  restrictions by storing deferments for directories, and changing the
  permissions (&c) after the archive has been fully read.

  Another good (?) idea here is to notice when the directory changes,
  and set the permissions then.  If a file comes along later that
  belongs in that dir, temporarily change the perms back.  This relies
  on the fact that most archives are in "canonical" order.

* Generate ls-style listings so we can browse with dired?  Look at how
  tar-mode works and see if changes could be made so that a generic
  archiving mode would be easy to write.


* incorporate all GNU tar features & extensions
* 4 interfaces to cpio code: cpio, pax, tar, backup (last 2 come
  later)
* 'copy-archive' mode (rewrite archive into archive).  Should be able
  to do this with multiple archives at once.
  This might require separating input and output buffers.  Certainly
  requires spliting archive_format variable into two.
* Convert all code into better style.  Should use function pointers
  for everything; no explicit cases.  Make it much easier to add a new
  format as desired.


* Write "garf" (GNU ARchive Format).  Why?  Because an extensible
  archiving format is a win.  We want to handle Mac, NT, etc files.
  Or, consider using extended ustar format as suggested in pax
  discussion.
* StuffIt format?
* Ability to write shar files?


================================================================

Questions:

* in copyin.c, how does append_flag interact with save_patterns?
* how do renaming options (eg, "-s" for pax) interact with links?
* in copyout.c: how does only-verify-crc mode interact with tar
  format?
* how does -s really interact with copy-pass?

* does rmt need --help and --version?

* make sure no-abs-path code works in all relevant cases.

* why not merge recursion processing in copypass and copyout?  The
  filesystem should be treated as just another back end.

* Does copy-pass handle sparse files?

* Is it faster to compile a glob pattern into a regexp and then apply
  that?

================================================================

backup:

* keep dumpdates-style database
* optionally keep index database
* way to estimate data to dump (how does Amanda handle this?)
* filesystem mode -- don't dump across FS boundaries [done]
* ensure integration with Amanda is simple

--xdev	 don't cross fs boundary
--index	 generate dump index file; put dump level in index file
--dumpdates=file
	 set dumpdates file
--indexfile=file
	 set index file
--restore
	 Restore mode.
--level=n
	 Only for dump mode; specifies dump level

By default indexfile is ".gnudumpindex" at top level of each
directory.  (Should this file be dumped??)

How to handle archive splits?  (Higher level tool)

================================================================

Done:

* Use newest autoconf
* Internationalize
* Update all Makefiles to GNU standards.  Test.  Consider allowing
  rewriting of program names.  [ automake handles all this ]

================================================================

Test:

* Add check for bug on DEC Alphas from John Heller.
@


1.3
log
@nothing
@
text
@d7 3
@


1.2
log
@updated for new autoconf/automake
@
text
@d11 2
@


1.1
log
@Many configuration fixes
@
text
@d9 2
@
