AW: [OpenAFS] Can anyone reproduce this under LINUX (was:
temporaryreference files do not disappear)
Dr. Dieter Mack
mack@uni-hohenheim.de
Tue, 18 Jun 2002 14:34:23 +0200 (MET DST)
I ran into these .__afsXXXX files a couple of years ago while trying to
migrate users home volumes to DFS. By inspecting these files you will find
that they are shell history files of old sessions, which usually are not
even closed properly, and hence may as well be empty. (These not properly
closed files caused the DFS file server to freeeze when touching the
migrated DFS files.) My analysis then (with the Korn shell on AIX) was, that
the shell removes the history file, transforming it to an .__afsXXXX file,
and then terminates. But once the login shell terminates, there is no token
anymore and hence the file cannot be deleted from the file server. I solved
this by placing an explicit /bin/rm -f $HOME/.__afs* in my .logout script,
which will remove them anyway. An other solution might be to remove them
in .profile during the next login.
This is why .__afsXXXX will disappear as expected in Dereks test program.
Regards, Dieter.
-------------
Dr. Dieter Mack Phone : +49 711 459 2838
Fax : +49 711 459 3449
Computer Center Email : Mack@uni-hohenheim.de
University of Hohenheim Mail : Schloss, Westhof-Sued
70593 Stuttgart
http://www.uni-hohenheim.de/rz/mack Germany
-------------
Disclaimer: My views and those of my employer have been known to differ.
On 14 Jun 2002, Derek Atkins wrote:
> I wrote a short program (RH7.1) but I cannot reproduce this problem.
> The program creates a file, unlinks it, prints a message, sleeps for
> 60 seconds, and then closes the file. While it's sleeping I get this:
>
> ~> ls -l
> total 18
> drwxrwxr-x 2 warlord mit 2048 Jun 14 18:14 .
> drwxr-xr-x 104 warlord root 16384 Jun 14 18:14 ..
> -rw-rw-r-- 1 warlord mit 0 Jun 14 18:14 .__afsDA45
> [7] Done /tmp/test
> ~> ls -l
> ls: .__afsDA45: No such file or directory
> total 18
> drwxrwxr-x 2 warlord mit 2048 Jun 14 18:14 .
> drwxr-xr-x 104 warlord root 16384 Jun 14 18:14 ..
> ~> ls -l
> total 18
> drwxrwxr-x 2 warlord mit 2048 Jun 14 18:15 .
> drwxr-xr-x 104 warlord root 16384 Jun 14 18:14 ..
>
> This is the program I used. Can you send a similarly-short program
> that reliably shows the problem?
>
> -derek
>
> #include <stdio.h>
>
> main ()
> {
> FILE *fp;
>
> fp = fopen ("test", "w+");
> if (!fp) {
> perror ("fopen");
> return -1;
> }
> unlink ("test");
> printf ("test unlinked...\n");
> sleep (60);
> fclose (fp);
> }
>
> Karl Amrhein <ksa@SLAC.Stanford.EDU> writes:
>
> > On Fri, Jun 14, 2002 at 10:27:15PM +0100, Paul Blackburn wrote:
> > > http://www.angelfire.com/hi/plutonic/afs-faq.html#sub2.19
> >
> > ...which says:
> >
> > "... As soon as the file gets closed, the
> > associated .__afsXXXX should disappear. "
> >
> > I think the point is that the associated .__afsXXXX files
> > are _not_ disappearing after the file gets closed.
> >
> > I am also seeing this behavior with mutt-1.3.25 and OpenAFS-1.2.4
> > on RH kernel 2.4.18-4smp (my mutt tmpdir is in my afs home dir).
> >
> > --
> > Karl Amrhein, <ksa@SLAC.Stanford.EDU> | www.slac.stanford.edu/~ksa
> > SLAC Computing Services, Systems Group | 650.926.5083 Bldg 50, 364
> > _______________________________________________
> > OpenAFS-info mailing list
> > OpenAFS-info@openafs.org
> > https://lists.openafs.org/mailman/listinfo/openafs-info
>
> --
> Derek Atkins, SB '93 MIT EE, SM '95 MIT Media Laboratory
> Member, MIT Student Information Processing Board (SIPB)
> URL: http://web.mit.edu/warlord/ PP-ASEL-IA N1NWH
> warlord@MIT.EDU PGP key available
> _______________________________________________
> OpenAFS-info mailing list
> OpenAFS-info@openafs.org
> https://lists.openafs.org/mailman/listinfo/openafs-info
>