On Sat, Sep 29, 2001 at 11:28:39PM +0100, David Taylor wrote:
[snip]
IMO, the below patch is probably the best solution.
Yep, it also fixes the fact that the return value from wait4() needs
to be preserved, at least for the return statement of __system().
G'luck,
Peter
--
yields falsehood,
Stijn Hoop wrote:
Any way using `` won't work. for i in a b c d works, for instance, but
there is not way that I know of that you can control the output this way
using ``.
Yes there is: set IFS to only contain a newline beforehand. That's my local
hack, your way is probably better :)
On Mon, Oct 01, 2001 at 10:56:24AM +0930, Greg Lehey wrote:
[Format recovered--see http://www.lemis.com/email/email-format.html]
On Friday, 28 September 2001 at 10:12:14 -0700, Julian Elischer wrote:
On Fri, 28 Sep 2001, Gersh wrote:
On Fri, 28 Sep 2001, Bernd Walter wrote:
On Fri, Sep
In message [EMAIL PROTECTED], Daniel C. Sobral cleopede:
Stijn Hoop wrote:
Any way using `` won't work. for i in a b c d works, for instance, but
there is not way that I know of that you can control the output this way
using ``.
Yes there is: set IFS to only contain a newline
Daniel C. Sobral([EMAIL PROTECTED])@2001.10.02 09:18:43 +:
Stijn Hoop wrote:
Any way using `` won't work. for i in a b c d works, for instance, but
there is not way that I know of that you can control the output this way
using ``.
Yes there is: set IFS to only contain a
[Bcc to -small as someone there might have had similar problems]
Hi,
I was trying to modify the picobsd build scripts so that the source
tree is entirely readonly. For the most part of it i think
i managed, the only missing part seems to be compilation of
new kernels.
config supports the -d
hi hackers,
I'm quite new to FreeBSD but not in UN*X, please let me ask a question:
I wonder that the filesystem performance under FreeBSD is so great. I'm
doing disk-to-disk file copies, like ``dd if=file1 of=file2 bs=64k'' and
the performance is much better than on other unices. Other systems
* Egervary Gergely [EMAIL PROTECTED] [011002 11:00] wrote:
hi hackers,
I'm quite new to FreeBSD but not in UN*X, please let me ask a question:
I wonder that the filesystem performance under FreeBSD is so great. I'm
doing disk-to-disk file copies, like ``dd if=file1 of=file2 bs=64k'' and
After Kris's recent report of 'massive speedups' using dirpref, I've
been toying with the idea of backing up my box, and then restoring them.
However, backup/restore are so much faster than doing a tar/untar.
If I do a backup of my FS, wipe the disk, will the 'restore' cause the
same
On Tue, Oct 02, 2001 at 11:05:00AM -0600, Nate Williams wrote:
If I do a backup of my FS, wipe the disk, will the 'restore' cause the
same (ineffecient) directory layout to appear on disk?
I wouldn't think so since the directory layout is controlled by the
kernel, but I do know that
In message [EMAIL PROTECTED], Nate Williams writes
:
After Kris's recent report of 'massive speedups' using dirpref, I've
been toying with the idea of backing up my box, and then restoring them.
However, backup/restore are so much faster than doing a tar/untar.
If I do a backup of my FS, wipe
After Kris's recent report of 'massive speedups' using dirpref, I've
been toying with the idea of backing up my box, and then restoring them.
However, backup/restore are so much faster than doing a tar/untar.
If I do a backup of my FS, wipe the disk, will the 'restore' cause the
same
On Tue, Oct 02, 2001 at 07:19:37AM -0700, Greg Shenaut wrote:
Is there any reason why the unbreakable space (0xa0) shouldn't be
the only kind of space character used/allowed in filenames?
Any character except for '/' is allowed in filenames, and I believe it's
been that way since the dawn of
I recommend using cpdup ( /usr/ports/sysutils/cpdup ), mainly because
you can ^C it and restart it at any time so it's a lot easier to
play around with your directory dup'ing.
-Matt
To Unsubscribe: send mail to [EMAIL PROTECTED]
with
In message [EMAIL PROTECTED], void cleopede:
On Tue, Oct 02, 2001 at 07:19:37AM -0700, Greg Shenaut wrote:
Is there any reason why the unbreakable space (0xa0) shouldn't be
the only kind of space character used/allowed in filenames?
Any character except for '/' is allowed in filenames, and I
On Tue, 2 Oct 2001, Peter Pentchev wrote:
On Mon, Oct 01, 2001 at 10:56:24AM +0930, Greg Lehey wrote:
[Format recovered--see http://www.lemis.com/email/email-format.html]
On Friday, 28 September 2001 at 10:12:14 -0700, Julian Elischer wrote:
On Fri, 28 Sep 2001, Gersh wrote:
On
Ok, I'm adding -hackers... another email thread got going in -committers.
Here is a patch set for -stable. It isn't perfect but it does appear
to solve the problem. The one case I don't handle right is if you have
a hardlinked file and two renames in two different directories
Hello,
There are problems with the Cyclades Cyclom YeP driver. (see PR
i386/30965). I've put printf's in the driver code on several places to
check where the point is of hard locking and its seems to be on line 136
in the /usr/src/sys/pci/cy_pci.c in my situation.
In message [EMAIL PROTECTED], Matt Dillon writes:
What I've done is add a SOFTLOCKLEAF capability to namei(). If set, and
the file/directory exists, namei() will generate an extra VREF() on
the vnode and set the VSOFTLOCK flag in vp-v_flag. If the vnode already
has VSOFTLOCK
On Tue, 02 Oct 2001, Alfred Perlstein wrote:
* Peter Pentchev [EMAIL PROTECTED] [011002 05:21] wrote:
On Sat, Sep 29, 2001 at 11:28:39PM +0100, David Taylor wrote:
[snip]
IMO, the below patch is probably the best solution.
Yep, it also fixes the fact that the return value from
Hi,
I'm creating an app where I want to use memory to store data so I
can get at it quickly. The problem is, I can't afford the delays that
would occur if the memory gets swapped out. Is there any way in FreeBSD
to allocate memory so that the VM system won't swap it out?
Thanks,
DMK
To
Dwayne wrote:
Hi,
I'm creating an app where I want to use memory to store data so I
can get at it quickly. The problem is, I can't afford the delays that
would occur if the memory gets swapped out. Is there any way in FreeBSD
to allocate memory so that the VM system won't swap it
Dwayne wrote:
I'm creating an app where I want to use memory to store data so I
can get at it quickly. The problem is, I can't afford the delays that
would occur if the memory gets swapped out. Is there any way in FreeBSD
to allocate memory so that the VM system won't swap it out?
I
* David Taylor [EMAIL PROTECTED] [011002 16:02] wrote:
On Tue, 02 Oct 2001, Alfred Perlstein wrote:
* Peter Pentchev [EMAIL PROTECTED] [011002 05:21] wrote:
On Sat, Sep 29, 2001 at 11:28:39PM +0100, David Taylor wrote:
[snip]
IMO, the below patch is probably the best solution.
Greg Shenaut [EMAIL PROTECTED] wrote:
I just throw out the idea--as for where to enforce such a convention,
I agree that the file-system definition may not be the best place,
but it might be the *easiest* place (spaces could be silently mapped
to 0xa0's).
Please don't even think about it.
Here is the latest patch I have. It appears to completely solve the
problem. I have shims in unionfs and nfs for the moment.
The patch is against -stable.
* Implements SOFTLOCKLEAF namei() option
* Implements EAGAIN error appropriate tsleep/retry code
* Universal
In message [EMAIL PROTECTED], Giorgos Keramidas cleopede:
Greg Shenaut [EMAIL PROTECTED] wrote:
I just throw out the idea--as for where to enforce such a convention,
I agree that the file-system definition may not be the best place,
but it might be the *easiest* place (spaces could be
Greg Shenaut [EMAIL PROTECTED] wrote:
Just out of curiosity, what would be an instance where you have
wanted a space in a filename and wouldn't have been satisfied with
0xa0 instead of 0x20?
All of them. Space is so conveniently placed under the tip of my thumb.
To type 0xa0 I would hav to
On Tuesday, 2 October 2001 at 12:43:54 -0700, Julian Elischer wrote:
On Tue, 2 Oct 2001, Peter Pentchev wrote:
On Mon, Oct 01, 2001 at 10:56:24AM +0930, Greg Lehey wrote:
[Format recovered--see http://www.lemis.com/email/email-format.html]
On Friday, 28 September 2001 at 10:12:14 -0700,
:
:Matt Dillon wrote:
: Here is the latest patch I have. It appears to completely solve the
: problem. I have shims in unionfs and nfs for the moment.
:
:This seems rather large compared to Ian Dowse's version.. Are you sure that
:you're doing this the right way? Adding a whole new
I need to take a directory of 'stuff'
which includes a script install.sh
and make it into a package..
I have had some success but it's not quite right..
What I'd like to make it do is:
unpack the 'stuff' into a temporary directory somewhere.
run the install script
delete the install
In message [EMAIL PROTECTED], Giorgos Keramidas cleopede:
Greg Shenaut [EMAIL PROTECTED] wrote:
Just out of curiosity, what would be an instance where you have
wanted a space in a filename and wouldn't have been satisfied with
0xa0 instead of 0x20?
All of them. Space is so conveniently
In message [EMAIL PROTECTED] Giorgos Keramidas writes:
: Greg Shenaut [EMAIL PROTECTED] wrote:
:
: I just throw out the idea--as for where to enforce such a convention,
: I agree that the file-system definition may not be the best place,
: but it might be the *easiest* place (spaces could be
In message [EMAIL PROTECTED] Greg Shenaut writes:
: But you have to admit, space is a character that has caused many
: problems in Unix filenames, because of the other Unix tradition of
: space-delimited word record handling. I usually use an underscore,
: myself, if I want a space-like
Greg Shenaut [EMAIL PROTECTED] types:
In message [EMAIL PROTECTED], void cleopede:
On Tue, Oct 02, 2001 at 07:19:37AM -0700, Greg Shenaut wrote:
Is there any reason why the unbreakable space (0xa0) shouldn't be
the only kind of space character used/allowed in filenames?
Any character
:
:Dwayne wrote:
: I'm creating an app where I want to use memory to store data so I
: can get at it quickly. The problem is, I can't afford the delays that
: would occur if the memory gets swapped out. Is there any way in FreeBSD
: to allocate memory so that the VM system won't swap it
Right, that was my question too, doesent seem connected with pre-emptive
kernels...
- Original Message -
From: Greg Lehey [EMAIL PROTECTED]
To: Julian Elischer [EMAIL PROTECTED]
Cc: Peter Pentchev [EMAIL PROTECTED]; Gersh [EMAIL PROTECTED]; Bernd
Walter [EMAIL PROTECTED]; Anjali Kulkarni
The problems all arise from the fact that we unlock the source
while we look up the destination, and when we return to relookup
the source, it may have changed/moved/disappeared. The reason to
unlock the source before looking up the destination was to avoid
deadlocking against ourselves on a lock
:The problems all arise from the fact that we unlock the source
:while we look up the destination, and when we return to relookup
:the source, it may have changed/moved/disappeared. The reason to
:unlock the source before looking up the destination was to avoid
:deadlocking against ourselves on
39 matches
Mail list logo
