Subject: bug#15879: closed ([PATCH 1/9] parted: fix EOF and ctrl-c handling)

From: [email-masked] (GNU bug Tracking System)
Date: Tue, 03 Dec 2013 15:06:03 +0000

Your bug report

#15879: [PATCH 1/9] parted: fix EOF and ctrl-c handling

which was filed against the parted package, has been closed.

The explanation is attached below, along with your original report.
If you require more details, please reply to [email-masked].

-- 
15879: http://debbugs.gnu.org/cgi/bugreport.cgi?bug=15879
GNU Bug Tracking System
Contact [email-masked] with problems

Subject: [PATCH 1/9] parted: fix EOF and ctrl-c handling
From: Phillip Susi <[email-masked]>
To: [email-masked]
Date: Tue, 03 Dec 2013 10:05:20 -0500
List-Id: <debbugs-submit.debbugs.gnu.org>

Duplicate, patch applied.

Subject: Re: [PATCH 1/9] parted: fix EOF and ctrl-c handling
From: Phillip Susi <[email-masked]>
To: "Brian C. Lane" <[email-masked]>, [email-masked]
Date: Tue, 12 Nov 2013 16:26:42 -0500
List-Id: <debbugs-submit.debbugs.gnu.org>

It has been a while again Brian so I thought I'd touch base again and
hope to push some patches this week and get on making a release.  I
agreed your patch was better than #4, fixed #5, agreed to table #7 for
now, and made sure #8 does not allow the user to create the errors.  I
just wanted to make sure that you came around on #6 and #9 before I
push them.

On 8/8/2013 8:45 PM, Brian C. Lane wrote:
> 1/9 - Ack. 2/9 - Ack. 3/9 - Ack. 0 sized data area just doesn't
> make sense anyway. 4/9 - Nak. I have a more general patch for this
> -- not everything inserts DMRAID in there. 5/9 - Shouldn't it use
> disk->dev->sector_size instead of hard-coded 512/1024? The logic
> seems a bit messy, using an if block instead of the == 1 ? 512 :
> 1024 may clean it up a little. If it is already set to 512 (or
> really ->sector_size) we don't need to walk the other partitions.
> One place where a tab snuck in. Looks pretty ok other than that. 
> 6/9 - Nak. I'm not sure if this is the right way to handle things. 
> 7/9 - Nak. I really don't like the giant pile of changes for a
> problem that is only in the gpt code. 8/9 - Nak. It looks to me
> like removing some of these checks is going to allow user (ui or
> library) checks that should fail on new data to pass. I'm ok with
> letting us run with these errors so we can fix them, but you
> shouldn't be able to enter bad numbers after the warnings. 9/9 -
> Nak. I need more details here. The reasoning in the original commit
> seems sound to me, and I'd be more worried about busy devices than
> the filesystem not matching (I'm not sure we should even be in the
> fs detection business anymore).
>