Re: [Linux-NTFS-Dev] Re: Re: ntfs resize and gtk frontends

[Andrew Clausen]

[cc'ing to bug-parted only]

On Fri, Jan 23, 2004 at 12:28:36PM +0100, Szakacsits Szabolcs wrote:
> 
> On Fri, 23 Jan 2004, Andrew Clausen wrote:
> 
> > This is one of my favourite stories!
> 
> Talking about favourites, here is my "favourite" challange. Since earlier
> ntfsresize could resize only if there weren't data after the new size,
> many people made the compromise "ok, let's shrink here now and more later
> on when/if I need/can" and some ended up in this situation:
> 
>   hda1 primary NTFS
>   hda2 primary linux
>   hda3 primary linux
>   hda4 extended
>   hda5 logical linux
>   ...
>                                                                               
>               
> Where could they put the space gained at the end of hda1 _without_
> changing and renumbering hda2, hda3, hda5? AFAIS nowhere. What would be
> the least pain for them? Merging the free space with hda2 but that's not
> supported (it could also break Linux boot, e.g. LILO used and hda2 has the
> kernel).

All kinds of things are possible with convertfs.  (I wonder if it
still works with 2.6.x)

It doesn't really sound like a serious concern though :p

> > >   - better logging of errors (probably should be to a file) and
> > 
> > Which file?  Where could it be saved? Maybe syslog?
> 
> Syslog seems overkill, probably not everywhere available, a bunch of
> unrelated messages, harder to get the info to recreate a problem
> (basically user defined format).

syslog is a nice standard, but I guess we don't want to be writing
things like partition table backups to it.

> But opening a file should work everywhere. Well, 'write' maybe not but
> most should have at least one read/write directory, probably /tmp.

What is a default?  (We don't really want to bother the user to make
a decision, right?)

> So it could be in /tmp or current directory or in /var/log or ... and make
> sure the user takes steps, if it's needed, the file won't get lost when
> the box is rebooted.

BTW, this will probably be on an initrd, right?
(It can't be on a file system being resized)

> > > Of course I agree. "If you can reproduce this bug with the latest version
> > > found at .... please send the 'parted.log' file.... ". Etc.
> > 
> > Perhaps a better solution would be to create some kind of hash
> > of the bug report message (which includes version number), and they
> > can type that hash in to see if a problem matching that description
> > has been fixed.
> 
> I thought about this also ("Etc" above :) The simplest implementation
> would be the 'Parted FAQ'.

I don't think this is very user-friendly, but it is simple :)

Cheers,
Andrew