On Mon, Oct 30, 2006 at 01:05:06PM -0800, Doug Barton wrote:
> Simon L. Nielsen wrote:
>
> > Personally I think rm should do what you ask it to do - if you ask it
> > to overwrite a file which has multiple links, well... though luck.
>
> Sorry, I disagree. It's not always obvious to the user wh
On Mon, October 30, 2006 4:51 pm, [EMAIL PROTECTED] wrote:
> I get a LOT of corrupt mailboxes. Just 187 mailboxes and daily
> problems. It's always the same error in the log files: "-ERR Unable to
> process From lines (envelopes), change recognition modes."
>
> I've done some research and don't kno
Is your spool over NFS?
You'll get those exact errors if you are on an NFS mount with spools
without some form of locking to prevent new message insertion into
existing messages.
On 10/30/06, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote:
I get a LOT of corrupt mailboxes. Just 187 mailboxes an
I get a LOT of corrupt mailboxes. Just 187 mailboxes and daily problems.
It's always the same error in the log files: "-ERR Unable to process From
lines (envelopes), change recognition modes."
I've done some research and don't know any more about where the problem
lives than I did before.
In <[EMAIL PROTECTED]>, Freddie Cash <[EMAIL PROTECTED]> typed:
> On Monday 30 October 2006 01:17 pm, Mike Meyer wrote:
> > In <[EMAIL PROTECTED]>, Doug Barton <[EMAIL PROTECTED]>
> typed:
> > > Simon L. Nielsen wrote:
> > > > Personally I think rm should do what you ask it to do - if you ask
> >
I will do that, thanks!
On Mon, 30 Oct 2006, Eric Anderson wrote:
> On 10/29/06 22:31, Geoff Mohler wrote:
>> Im looking for deep hacks into what I could do to make the 6.x NFS client
>> hold a larger (or much larger) file/directory attribute cache.
>>
>> In very large make "everything" environ
Mike Meyer wrote:
> In <[EMAIL PROTECTED]>, Doug Barton <[EMAIL PROTECTED]> typed:
>> Simon L. Nielsen wrote:
>>> Personally I think rm should do what you ask it to do - if you ask it
>>> to overwrite a file which has multiple links, well... though luck.
>> It's all well and good to say, "tough l
On Monday 30 October 2006 01:17 pm, Mike Meyer wrote:
> In <[EMAIL PROTECTED]>, Doug Barton <[EMAIL PROTECTED]>
typed:
> > Simon L. Nielsen wrote:
> > > Personally I think rm should do what you ask it to do - if you ask
> > > it to overwrite a file which has multiple links, well... though
> > > lu
In <[EMAIL PROTECTED]>, Doug Barton <[EMAIL PROTECTED]> typed:
> Simon L. Nielsen wrote:
> > Personally I think rm should do what you ask it to do - if you ask it
> > to overwrite a file which has multiple links, well... though luck.
> It's all well and good to say, "tough luck," but I don't thin
Simon L. Nielsen wrote:
> Personally I think rm should do what you ask it to do - if you ask it
> to overwrite a file which has multiple links, well... though luck.
Sorry, I disagree. It's not always obvious to the user when a file has
hard links, and I can't see any situation where the pre-rec
--- Bakul Shah <[EMAIL PROTECTED]> wrote:
> Sorry if I tuned in late:-)
>
> I vote for taking *out* -P. It is an ill-designed
> feature.
> Or if you keep it, also add it to mv, cp -f & ln -f
> since
> these commands can also unlink a file and once
> unlinked in
> this matter you can't scrub it
On 2006.10.30 21:31:51 +1100, Peter Jeremy wrote:
> On Mon, 2006-Oct-30 19:38:49 +1100, Peter Jeremy wrote:
> >the user is unaware that there are multiple links. I don't think
> >that just unlinking the file and issuing a warning is a good solution
> >because it's then virtually impossible to loca
Doug Barton writes:
> Bakul Shah wrote:
> > Sorry if I tuned in late:-)
> >
> > I vote for taking *out* -P. It is an ill-designed feature.
> > Or if you keep it, also add it to mv, cp -f & ln -f since
> > these commands can also unlink a file and once unlinked in
> > this matter you can't scrub i
Bakul Shah wrote:
> Sorry if I tuned in late:-)
>
> I vote for taking *out* -P. It is an ill-designed feature.
> Or if you keep it, also add it to mv, cp -f & ln -f since
> these commands can also unlink a file and once unlinked in
> this matter you can't scrub it. And also fix up the behavior
>
Sorry if I tuned in late:-)
I vote for taking *out* -P. It is an ill-designed feature.
Or if you keep it, also add it to mv, cp -f & ln -f since
these commands can also unlink a file and once unlinked in
this matter you can't scrub it. And also fix up the behavior
for -P when multiple links. An
Peter Jeremy wrote:
> On Sun, 2006-Oct-29 18:11:54 -0800, [EMAIL PROTECTED] wrote:
>> I think a very strong case can be made that the *intent* of -P --
>> to prevent retrieval of the contents by reading the filesystem's
>> free space -- implies that it should affect only the "real" removal
>> of th
If I'm not mistaken pjd@ has written similar module which is called
lrexec for RELENG_4 and RELENG_5. See his web site.
Also recently rwatson@ enabled audit support in RELENG_6 and CURRENT,
though I don't know yet whether it can log arguments.
Great, lrexec was exactly what I was looking for
On Mon, 2006-Oct-30 17:39:54 +0800, LI Xin wrote:
>Well thought, I think that you are correct that specifying -P should do
>nothing but generate a warning.
>
>In addition to this I have changed the behavior a bit (patch attached)
>that, if -f is specified along with -P, the overwritten is happen an
Hello,
I am currently writing my first kernel module to extract data from
the kernel and bring it into user-space. As I understand, FreeBSD
only loads pages of the text segment that it is about to use by
registering its handler for page faults, and bringing in more pages
from the binary as needed
On Mon, Oct 30, 2006 at 03:47:37PM +0200, Kostik Belousov wrote:
>
> I think that David is right. The references _from_ the directory make it
> immune
> to vnode reclamation. Try this patch. It is very unfair for lsof.
Sorry, but I'm leaving now and I'll be unable to play with your
patch until I
On 10/29/06 22:31, Geoff Mohler wrote:
Im looking for deep hacks into what I could do to make the 6.x NFS client
hold a larger (or much larger) file/directory attribute cache.
In very large make "everything" environments with Fbsd, we are about 1/3rd
the speed of local disk coming from a very
On Mon, 30 Oct 2006, Dave Clausen wrote:
I'm a n00b to the FreeBSD kernel and I'm trying to log all commands run on
the command line from within the kernel for security purposes by loading a
kernel module which redefines execve(). I've successfully created the KLD
and have it working, but am
Im looking for deep hacks into what I could do to make the 6.x NFS client
hold a larger (or much larger) file/directory attribute cache.
In very large make "everything" environments with Fbsd, we are about 1/3rd
the speed of local disk coming from a very large Netapp box.
The same make from a h
It would be good to get some sysadmin focussed freebsd talks
from people based in the UK - we had a number last year
which worked very well.
Given the time scale, feel free to offer a half-formed idea
and supply more details later.
Regards
Sam
__START__
UKUUG's annual Large Installation Syst
On Mon, Oct 30, 2006 at 04:05:19PM +0300, Yar Tikhiy wrote:
> On Sun, Oct 29, 2006 at 11:32:58AM -0500, Matt Emmerton wrote:
> > [ Restoring some OP context.]
> >
> > > On Sun, Oct 29, 2006 at 05:07:16PM +0300, Yar Tikhiy wrote:
> > >
> > > > As for the said program, it keeps its 1 Hz pace, mostly
On Mon, Oct 30, 2006 at 04:05:19PM +0300, Yar Tikhiy wrote:
> On Sun, Oct 29, 2006 at 11:32:58AM -0500, Matt Emmerton wrote:
> > [ Restoring some OP context.]
> >
> > > On Sun, Oct 29, 2006 at 05:07:16PM +0300, Yar Tikhiy wrote:
> > >
> > > > As for the said program, it keeps its 1 Hz pace, mostly
On Sun, Oct 29, 2006 at 11:32:58AM -0500, Matt Emmerton wrote:
> [ Restoring some OP context.]
>
> > On Sun, Oct 29, 2006 at 05:07:16PM +0300, Yar Tikhiy wrote:
> >
> > > As for the said program, it keeps its 1 Hz pace, mostly waiting on
> > > "vlruwk". It's killable, after a delay. The system d
Peter Jeremy wrote:
> On Mon, 2006-Oct-30 19:38:49 +1100, Peter Jeremy wrote:
>> the user is unaware that there are multiple links. I don't think
>> that just unlinking the file and issuing a warning is a good solution
>> because it's then virtually impossible to locate the other copy(s)
>> of the
On Sun, Oct 29, 2006 at 03:22:27PM +, David Malone wrote:
> On Sun, Oct 29, 2006 at 05:07:16PM +0300, Yar Tikhiy wrote:
> > Weird, eh? Any ideas what's going on?
>
> I would guess that you need a new vnode to create the new file, but no
> vnodes are obvious candidates for freeing because they
On Mon, 2006-Oct-30 19:38:49 +1100, Peter Jeremy wrote:
>the user is unaware that there are multiple links. I don't think
>that just unlinking the file and issuing a warning is a good solution
>because it's then virtually impossible to locate the other copy(s)
>of the file, which remains viewable.
Joerg Pernfuss wrote:
> On Mon, 30 Oct 2006 19:38:49 +1100
> Peter Jeremy <[EMAIL PROTECTED]> wrote:
>
>> I agree. Doing "rm -P" on a file with multiple links suggests that
>> the user is unaware that there are multiple links. I don't think
>> that just unlinking the file and issuing a warning i
> > protections at a later date. Unless Alice notices that her file
> > has a second link before she deletes it, when she issues "rm -P",
> > she will lose her link to the file (and her only way of uniquely
> > identifying it) whilst leaving the remaining link to the file in
> > Mallory's control
Peter Jeremy wrote:
> On Mon, 2006-Oct-30 03:32:09 +, Xin LI wrote:
>> Be more reasonable when overwrite mode is specified while there
>> is hard links. Overwritting when links > 1 would cause data
>> loss, which is usually undesired.
>
> Another way of looking at it is that not overwritin
On Mon, 30 Oct 2006 19:38:49 +1100
Peter Jeremy <[EMAIL PROTECTED]> wrote:
> I agree. Doing "rm -P" on a file with multiple links suggests that
> the user is unaware that there are multiple links. I don't think
> that just unlinking the file and issuing a warning is a good solution
> because it'
On Sun, 2006-Oct-29 18:11:54 -0800, [EMAIL PROTECTED] wrote:
>I think a very strong case can be made that the *intent* of -P --
>to prevent retrieval of the contents by reading the filesystem's
>free space -- implies that it should affect only the "real" removal
>of the file, when its blocks are re
On Sun, Oct 29, 2006 at 04:13:24PM +0100, Ulrich Spoerlein wrote:
> Yar Tikhiy wrote:
> > Weird, eh? Any ideas what's going on?
>
> None, but have you tried without soft updates?
Yes, I tried, but no soft updates didn't affect the picture.
--
Yar
___
Don't forget logging the environment as well as the command line. Many
programs will treat environment variables as arguments.
adrian
--
Adrian Chadd - [EMAIL PROTECTED]
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/li
37 matches
Mail list logo
