> My observation is that such cosmetic changes (like changing comments and
> memset/memcpy) are rejected by Hurd core developers when they are alone,
> so the only way to commit them is to merge them with more essential patch.
You are exactly wrong.
___
Debian Bug #190732 can be safely closed. The patch you're talking
about is in http://sv.gnu.org/patch/?func=detailitem&item_id=1839
too.
Okie.
> What bug did this patch fix exactly? Do you have any test cases
> for this?
Many small bugs are fixed. Most of the sentences in th
Debian Bug #190732 can be safely closed. The patch you're talking about
is in http://sv.gnu.org/patch/?func=detailitem&item_id=1839 too.
Alfred M. Szmidt wrote:
What bug did this patch fix exactly? Do you have any test cases for
this?
Many small bugs are fixed. Most of the sentences in the cha
2003-07-29 Ognyan Kulev <[EMAIL PROTECTED]>
* dir-renamed.c (checkpath): Redundant assignment is removed.
(diskfs_rename_dir): Remove variable BUF.
Space for DS is allocated with alloca.
When renaming node to itself, goto out instead of repeating co
Ognyan Kulev wrote:
The patch is ready, but it doesn't revert back st_nlink:s. There are
many small changes so it would be good if someone else take a careful
look too. It features verbose changelog entries too.
The simple patch is committed. The long patch is updated and attached
to this mai
Alfred M. Szmidt wrote:
Please don't use {} in ChangeLogs.
You're right. An updated changelog is attached.
Regards
--
Ognyan Kulev <[EMAIL PROTECTED],fsa-bg.org}>
7D9F 66E6 68B7 A62B 0FCF EB04 80BF 3A8C A252 9782
2003-07-27 Ognyan Kulev <[EMAIL PROTECTED]>
* dir-renamed.c (checkpath):
Ognyan Kulev wrote:
I'll try to address this and other problems
(like reverting back st_nlink when error occurs) in a "final" patch soon.
The patch is ready, but it doesn't revert back st_nlink:s. There are
many small changes so it would be good if someone else take a careful
look too. It feat
Ognyan Kulev wrote:
BTW There is a possible deadlock in this function when source and
destination parent directories are different.
This is wrong. Actually, all renames are serialized
(libdiskfs/dir-rename.c:24).
Regards
--
Ognyan Kulev <[EMAIL PROTECTED],fsa-bg.org}>
7D9F 66E6 68B7 A62B 0FCF
Ognyan Kulev <[EMAIL PROTECTED]> writes:
> Marco Gerards wrote:
> > Ognyan Kulev <[EMAIL PROTECTED]> writes:
> >>$ mkdir d
> >>$ cd d
> >>$ mkdir x
> >>$ mv x y
> >>$ mv y x
> > I've tested this both with and without your patch. Nothing (weird)
> > happened.
>
> (I suppose you are talking about y
Marco Gerards wrote:
Ognyan Kulev <[EMAIL PROTECTED]> writes:
$ mkdir d
$ cd d
$ mkdir x
$ mv x y
$ mv y x
I've tested this both with and without your patch. Nothing (weird)
happened.
(I suppose you are talking about your patch, not about mine.) I tried
your patch and, suprisingly for me, the ass
Ognyan Kulev <[EMAIL PROTECTED]> writes:
> Please run exactly the following commands and tell us what's happening
> after _the last one_.
>
> $ mkdir d
> $ cd d
> $ mkdir x
> $ mv x y
> $ mv y x
I've tested this both with and without your patch. Nothing (weird)
happened.
--
Marco
_
On Wed, Jul 16, 2003 at 05:59:20AM -0500, Marcus Brinkmann wrote:
> On Wed, Jul 16, 2003 at 01:26:20AM +0300, Ognyan Kulev wrote:
> > On Tue, Jul 15, 2003 at 05:43:24AM -0500, Marcus Brinkmann wrote:
> > > 1. What errors do you still expect from the second time diskfs_lookup is
> > > invoked with R
On Wed, Jul 16, 2003 at 08:17:28PM +0200, Marco Gerards wrote:
> Marco Gerards <[EMAIL PROTECTED]> writes:
>
> > I have a look at this patch tommorrow to check if it has the same
> > problem with my patch and send in a new patch or I'll say what the
> > problem is.
>
> The patch worked perfectly
Marco Gerards <[EMAIL PROTECTED]> writes:
> I have a look at this patch tommorrow to check if it has the same
> problem with my patch and send in a new patch or I'll say what the
> problem is.
The patch worked perfectly for me!
As I've promissed, I've included my version with this mail. Perhaps
On Wed, Jul 16, 2003 at 01:26:20AM +0300, Ognyan Kulev wrote:
> On Tue, Jul 15, 2003 at 05:43:24AM -0500, Marcus Brinkmann wrote:
> > 1. What errors do you still expect from the second time diskfs_lookup is
> > invoked with REMOVE? Is there any error that is allowed at that time?
> > If there is,
Marcus Brinkmann <[EMAIL PROTECTED]> writes:
> Hi,
>
> I think the first patch is basically correct, although I wonder about
> the following details:
>
> 1. What errors do you still expect from the second time diskfs_lookup is
> invoked with REMOVE? Is there any error that is allowed at that ti
On Tue, Jul 15, 2003 at 05:43:24AM -0500, Marcus Brinkmann wrote:
> 1. What errors do you still expect from the second time diskfs_lookup is
> invoked with REMOVE? Is there any error that is allowed at that time?
> If there is, the change is correct.
Before the second diskfs_lookup, mutex_unlock
Hi,
I think the first patch is basically correct, although I wonder about
the following details:
1. What errors do you still expect from the second time diskfs_lookup is
invoked with REMOVE? Is there any error that is allowed at that time?
If there is, the change is correct.
2. Is it possible,
Hi,
I made a somewhat reworked version of lbidiskfs/dir-renamed.c. This is
the second attached patch. As you may guess, I prefer it over the other
one.
But there is a much smaller patch that fixes the bug too. It is the
first attached patch.
Regards
--
Ognyan Kulev <[EMAIL PROTECTED]>, "\"
19 matches
Mail list logo
