Szakacsits Szabolcs wrote:
> man ntfsresize:
>
> ntfsresize conforms to the SI, ATA, IEEE standards and
> the disk manufacturers by using k=10^3, M=10^6 and G=10^9.
>
> fdisk, cfdisk, reiser_reiserfs use the same decimal units and parted was
> supposed to be converted too 2 years ago but that still didn't happen.
Partman looks at the part of the ntfsresize output that gives a value in
bytes. That value was, like I said, output as exactly 3231584256 bytes,
correctly as far as I can tell. No matter what you call a k M or G, a
byte is a byte.
> > [1] clue to ntfsresize developers: if you have to add a
> > /* WARNING: don't modify the text, external tools grep for it */
> > then you're doing something wrong; add a new command line option
> > with a decent interface!
>
> What decent interface do you suggest? I'm listening.
ntfsresize --print-min-size <partition>
# outputs an integral number of bytes followed by a newline
> BTW, _please_ don't make the same mistake as Mandrake, RedHat/Fedora, SUSE
> and many other distros by releasing 2.6 kernel without unfixed parted (or
> old parted without unfixed 2.6 kernel). I'm sure you're aware of the
> problem because I've seen several Sarge bug reports about trashed
> partition tables already.
AFAIK our parted is fixed.
parted (1.6.11-1) experimental; urgency=low
* New upstream release. (Closes: #254502)
- should fix 2.6 kernel BIOS CHS geometry problems. Broke binary
compatibility though, thus the soname change.
Later made it into unstable, and testing. In my tests ntfs resize works ok
with 2.6 kernel and windows continues to boot. Howrever, this is after
already writing a partition table and resizing the same windows install
once before, using a 2.4 kernel the first time. If that matters, I could
do (ugh) another windows install.
--
see shy jo
Attachment:
signature.asc
Description: Digital signature