Subject: .nfs2000820f0000000b file appearing

From: "S.Toms" <[email-masked]>
Date: Sat, 17 Jun 2000 08:06:42 -0700 (PDT)

I've been using a crontab routine on my mailserver that checks to see if
the various mailfiles are empty and deletes them so they nolonger show in
the mailbox list. It works pretty good with the occasional "ACCESS
ERROR" that occurs when the mailbox is deleted as procmail writes to it.
  Now I tried to make it better by also adding a -amin parameter to it
like so:

find '/home/skull/mail/Mailing Lists' -amin +5 -empty -exec rm -f {} \;

but it tends to delete instantly rather then wait 5 min. So I tried adding
it to the workstation to see what happens and it ends up placing the
.nfs2000808400000002 file within the directory which then causes crontab
to report the following

    rm: cannot unlink `/home/skull/mail/Mailing
    Lists/.nfs2000820f0000000b': Device or resource busy

  Anyone have any thoughts as to why or what is happening?

-- 
        S.Toms - [email-masked] - www.primenet.com/~tomas
                   SuSE Linux v6.3+ - Kernel 2.2.14

-- 
-----------------------------------------------------------------
 For information about this mailing list, and its archives, see: 
 http://www.washington.edu/pine/pine-info/
-----------------------------------------------------------------

---

From: Emil Isberg <[email-masked]>
Date: Sat, 17 Jun 2000 19:54:33 +0200 (MET DST)

>ERROR" that occurs when the mailbox is deleted as procmail writes to it.

I would rather create a shellskript (or similar) that does access checks
(locks the file before removal and such things)...

find is not that good at checking mailboxes...

>.nfs2000808400000002 file within the directory which then causes crontab

If your workstations clock and servers clock is not in sync with each 
other then you can't really depend on that small amount of time...
(When the workstations say that it's now the server might think it was ten
minutes ago or so.)

But that .nfs* file you are seeing is a file that you've removed from a
nfsmounted directory and is opened by a program on some other server or
workstation...

You shouldn't remove that.

Another thing when dealing with nfsmounted directories you can't depend on
the filetimes as good as if it was a local time. NFS caches the writes and
updates so that it surely isn't synced all of the time (unless you give
som optionflag to the mountcommand).

I don't have any suggestion that will solve your problem though, but you
might be able to raise the time to one hour or so.

-- 
Mistakes are oft the stepping stones to utter failure.

---

From: "S.Toms" <[email-masked]>
Date: Sat, 17 Jun 2000 16:50:28 -0700 (PDT)

On Sat, 17 Jun 2000, Emil Isberg wrote:

ei> On Sat, 17 Jun 2000, S.Toms wrote:
ei> >  I've been using a crontab routine on my mailserver that checks to see if
ei> >the various mailfiles are empty and deletes them so they nolonger show in
ei> >the mailbox list. It works pretty good with the occasional "ACCESS
ei> >ERROR" that occurs when the mailbox is deleted as procmail writes to it.
ei> 
ei> I would rather create a shellskript (or similar) that does access checks
ei> (locks the file before removal and such things)...
ei> 

  Not sure how to do that, or if I do, I'm not understanding exactly what
you mean :)

ei> find is not that good at checking mailboxes...
ei> 

  True, but until I can come up with a better way, it'll have to do. It's
definately not the most eligent.

ei> >but it tends to delete instantly rather then wait 5 min. So I tried adding
ei> >it to the workstation to see what happens and it ends up placing the
ei> >.nfs2000808400000002 file within the directory which then causes crontab
ei> >to report the following
ei> 
ei> If your workstations clock and servers clock is not in sync with each 
ei> other then you can't really depend on that small amount of time...
ei> (When the workstations say that it's now the server might think it was ten
ei> minutes ago or so.)
ei> 
  Kinda thought that was the case when I read it after posting it, sure
enough, did a date check and the clocks were 10min off, I enabled xntpd to
sync the clocks so we'll see if that helps for the time being.

ei> But that .nfs* file you are seeing is a file that you've removed from a
ei> nfsmounted directory and is opened by a program on some other server or
ei> workstation...
ei> 

  You know, I didn;t even think about nfs being a problem, but that makes
perfect sense, especially considerign the name of the file.

ei> You shouldn't remove that.
ei> 

 well removing it was the only way to get rid of the crontab error, but I
had to do it manually.

ei> Another thing when dealing with nfsmounted directories you can't depend on
ei> the filetimes as good as if it was a local time. NFS caches the writes and
ei> updates so that it surely isn't synced all of the time (unless you give
ei> som optionflag to the mountcommand).
ei> 

 wasn't aware of that, I'll have to take a look at that too I guess.

ei> I don't have any suggestion that will solve your problem though, but you
ei> might be able to raise the time to one hour or so.
ei> 

 well you cleared some things up for me, so that was a big help
already. I'll see what I can come up with script wise, but hopefully
something turns up in pine in the near future that will take care of this
for us. I heard rumor of something that shows the message count in the
mailbox list or somethign to that affect.
  Anyway, thanks for the reply.

ei>

---

From: Walt Smith <[email-masked]>
Date: Thu, 22 Jun 2000 09:03:16 -0400 (EDT)

Would anybody else like to have the filter rules enhanced in such a way so
as to permit the setting up of an autorespond capability based on
keyword(s) in the Subject field?  I know that it's possible to do this via
Procmail, but that's difficult and one misconfiguration can hose almost
all your email list subscriptions (as I know from experience).  It'd sure
be nice to have an autorespond function where you could enter your keyword
and check an autorespond option, then enter the name of the file to be
sent back.  There aren't many functions that I personally think ought to
be added to Pine, but now that the filter rules are here, this would be an
absolutely superb enhancement.

-- 
Walt Smith - Raleigh, NC
[email-masked]