[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Re: ntfs resize and gtk frontends

From: Szakacsits Szabolcs
Subject: Re: Re: ntfs resize and gtk frontends
Date: Fri, 23 Jan 2004 02:19:02 +0100 (MET)

On Fri, 23 Jan 2004, Andrew Clausen wrote:
> On Thu, Jan 22, 2004 at 04:18:10PM +0100, Szakacsits Szabolcs wrote:
> >   - one of the most disliked one described below, even a patch is provided
> >     to solve it (at least partly),
> > 
> >     http://mail.gnu.org/archive/html/bug-parted/2003-05/msg00046.html
> > 
> >     Knowing where things are in sector level is very important 
> >     occasionally.
> This patch only solves half the problem.  I guess it's the important
> half though.  (The other half is getting Parted to talk to you in
> custom units)

Couldn't that part be used/applied until the left is done? I mean, would
it add extra functionality without breaking things?
> Besides, this usually isn't a problem, because things get rounded
> in a big way for alignment stuff.

I would be interested how this rounding happens. 

[cs]fdisk has the "problem" it rounds sometimes ceiling sometimes floor to
cylinder boundary. Thus if one follows the rule for shrinkage "make the
partition bigger than the filesystem" found in the resize2fs,
resize_reiserfs and ntfsresize man pages then he/she can end up in a
situation where the partition end being in the middle of the filesystem.
So just trying the logic

        1. resize fs to 'X'
        2. resize partition to 'X' + 'Y' where 'Y' > 0

isn't guaranteed to work if 'Y' isn't big enough because the tools can
round down enough to cylinder boundary to cause this problem. I don't know
how ext[23] and reiserfs handle this but NT4, W2K, XP, W2K3, etc won't
boot [well, probably it's better than crashing half/one year later]. Just
by recreating the partition to be bigger fixes the problem (many people
had this).

In short, they should always round ceiling to avoid this problem. If it's
possible of course.
> >   - no save/restore partition table functionality. Partitioning is very
> >     messy, complicated, a lot of scenarios. When somethings goes wrong
> qtparted allows you to "commit".  

I didn't check it out yet but I've seen some messages when people were
confused what's happening. Well, I admit I don't know what's the
"traditional" way to do these with GUI ...

> I think this is a better solution (but both features are good)

The other feature has another benefit what I forgot to mention earlier.
Debug, troubleshooting. If there is a problem then user could just send
the file for investigation, bug reproduction.
> >   - "report this .... bug" instead of "check out ... for updates, etc"
> >     Unfortunately there isn't any Changelog/FAQ on the Parted site, not to
> >     mention link to the latest release.
> Is this really important?  Perhaps we should have a separate bug
> list to the main list.

I don't think a new list is needed but 

        - announcements of the new versions or just stating the latest
          stable release version, data (or so) on the Parted web page

        - better logging of errors (probably should be to a file) and
          asking users to send that

could contribute for improving things in the long term (easier bug fixes
and more free time since no "need" to answer the same questions => better
user satisfaction).
> I think it's best to minimize the time users have to spend to report
> a bug - otherwise they won't bother.

Of course I agree. "If you can reproduce this bug with the latest version
found at .... please send the 'parted.log' file.... ". Etc.

        [ parted in ocaml ]
> > I'm afraid it wouldn't be :) 
> I would like it, if that counts!

> >   - most distros ship parted but I don't know any who ships ocaml
> Debian :)

Well, in that case Mandrake also :) 

reply via email to

[Prev in Thread] Current Thread [Next in Thread]