(This appeared to bounce the first time I sent it; my apologies if it
arrives twice...)

> There is one general problem with GNUtar and incrementals:
> The unix ctime must not change. Otherwise you get just this 
> result incrementals being full backups.
> 
> The typical reason for changing ctimes is GNUtar running
> with --atime-preserve option. You might check your runtar debug
> files for this option and verify with ls -al --time=ctime
> <some important file or directory which hasn't changed that your
> ctime are correct.

I think we're on to something here!

[root ~]% ls -lhBF /home/proj/bp-9725/
total 24k
drwxrwxrwx    2 ken      users        4.0k Aug  9 15:31 bpip/
drwxrwxrwx    8 ken      users        4.0k Jul 25 07:17 calpuff/
drwxrwxrwx    7 eric_a   users        4.0k Aug 24 02:44 contemp.cpuf/
drwxrwxrwx    4 eric_a   users        4.0k Jul 24 15:32 isc/
drwxrwxrwx    2 ken      users        4.0k Jun 27 10:39 met/
drwxrwxrwx    2 eric_a   users        4.0k Jul 26 15:29 send/

[root ~]% \ls -al --time=ctime /home/proj/bp-9725/
total 32
drwxrwxrwx    8 ken      users        4096 Aug 26 06:00 .
drwxrwxrwx   28 root     root         4096 Aug 15 15:08 ..
drwxrwxrwx    2 ken      users        4096 Aug 26 06:00 bpip
drwxrwxrwx    8 ken      users        4096 Aug 26 06:00 calpuff
drwxrwxrwx    7 eric_a   users        4096 Aug 26 06:00 contemp.cpuf
drwxrwxrwx    4 eric_a   users        4096 Aug 26 06:00 isc
drwxrwxrwx    2 ken      users        4096 Aug 26 06:00 met
drwxrwxrwx    2 eric_a   users        4096 Aug 26 06:00 send

The ctimes appear to have changed this morning at 6:00 AM.  Checking several
other directories and finding the ctimes to be also 6:00 AM leads my
thoughts away from amanda and to a little scripty-boy hack that I run from
crontab every morning at 6:00.  

The default permissions for newly created files and directories on this disk
are 644 and 755, respectively.  /home/proj is a space for shared projects,
where many people work on the same sets of files (e.g. ken and eric_a
above).  The script does essentially this:

foreach user (...list of users...)
    foreach dir (home/proj/*)
        if (-eof $dir) chmod -f  goa+rw $dir
        if (-ed $dir)  chmod -fR goa+rw $dir
    end
end

That is, it recursively sets all the permissions to 666 and 777,
respectively.  AND CHANGES THE CTIME!  D'oh!  I didn't realize that amanda
was going off the ctime, not the time that's listed by a normal `ls -lF`.  

I did this because people were constantly forgetting to chmod files they
created.  Setting umask to 002 would also make files they create in their
own home directories (/home/user) public, which is not right.  I don't know
of a way to set umask to 022 for some directories and not for others.  The
man page for chmod doesn't list a switch like --preserve-ctimes.  

So this should fix amanda's problem (YAY!) that's been plaguing me for a
long time, but it re-introduces the chmod/umask problem.  After some messing
around, I added a line to the system-wide csh.cshrc file:

alias cwdcmd "source /etc/cwdcmd"

where the latter file is

if ($PWD =~ /home/proj*) then
    umask 000
else
    umask 022
endif

I can't figure out how to do conditional execution inside an alias, so I had
to source a file.  "alias cwdcmd 'if ($PWD =~ /home/proj*) then; umask 000;
else umask 022; endif'" doesn't work.  If anyone knows how to do use an if
statement inside an alias, please let me know...

Thanks so much to Dietmar Goldbeck, Paul Bort, Jean-Louis Martineau, Frank
Smith, Gene Heskett, and everyone else who helped me track down the source
of this problem!

Bart

Bart
---
Bart Brashers                           MFG Inc.
Air Quality Meteorologist               19203 36th Ave W Suite 101
bart.brashers AT mfgenv DOT com            Lynnwood WA 98036-5707
http://www.mfgenv.com                   425.921.4000 Fax: 425.921.4040