AW: AW: [OpenAFS] Can anyone reproduce this under LINUX (was: temporaryreference files do not disappear)
Rubino Geiß
kb44@rz.uni-karlsruhe.de
Tue, 18 Jun 2002 14:52:16 +0200
This is not true in every case, as I already posted you can get this
files not to go away properly, with a tick you can do it: "./close ; ls
-la ; unlog ; ls -la"
The second ls -la result in a permission denied, but if you log in again
on a different or the same workstation, the .__afs file is still there!
In my opinion this (a event that is equal to an unlog) can happen if a
network fails, the workstation fails or most likely X is dieing or being
killed. The token becomes invalid immediately, and no one can do
something against it?! The temporary file will remain... because the
client (cache manager) it simply not authorized to delete it (no
token!!!).
By the way, it appears that these files reside only in cache dirs of
browsers and in .gconf/. Their creation time is spread wide and there
size is not always 0.
-----
The above text is a clarification of a pervious post.
Bye, ruby
PS: a browser cache may be similar to the history file you experienced
years ago.
-----Ursprüngliche Nachricht-----
Von: Dr. Dieter Mack [mailto:mack@uni-hohenheim.de]
Gesendet: Dienstag, 18. Juni 2002 14:34
An: Derek Atkins
Cc: Karl Amrhein; Paul Blackburn; Rubino Geiß; openafs-info@openafs.org
Betreff: Re: AW: [OpenAFS] Can anyone reproduce this under LINUX (was:
temporaryreference files do not disappear)
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
>