Re: Re: ntfs resize and gtk frontends
On Fri, Jan 23, 2004 at 11:06:00AM +1100, Andrew Clausen wrote: On Thu, Jan 22, 2004 at 08:16:32PM +0100, Szakacsits Szabolcs wrote: This is a real problem, but again not one of libparted per see, more one linked to the fact that there is no open CVS or whatever repository. This has to be solved soon, or parted will be forked or something. E.g. somebody (you? :) could help out Andrew and if he still won't have time then incrementally take over maintainership, or something :) I have no objection to this. The only reason I have a priviledged position is because the way uploads to ftp.gnu.org used to work. I can add Sven's GPG signature, for after when they apply the md5sums. Fine with me. I have no idea of how the exact process works, and what you mean by 'they apply the md5sums', i guess this means that when they finish setting up the repositories so signed md5sums files are used to guarantee the uploads or something such ? But what i really think is necessary, is a CVS or better yet arch or subversion repository. You said you would investigate about this, what did you learn. Sven: can you give me your GPG key and phone number? My key is : 709141A4 and it is my debian key, so it is in the debian web of trust, and my identity has been checked when it was signed. My phone number i will send you in private, if it is ok for you ? Friendly, Sven Luther -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Re: ntfs resize and gtk frontends
On Fri, Jan 23, 2004 at 02:19:02AM +0100, Szakacsits Szabolcs wrote: - most distros ship parted but I don't know any who ships ocaml Debian :) Well, in that case Mandrake also :) All major distros do, i think. After all it is used in software as mldonkey, coq, and apparently also somewhere in the dependency chain of subversion, altough i was not able to confirm this latest one. Friendly, Sven Luther -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: [Linux-NTFS-Dev] Re: Re: ntfs resize and gtk frontends
On Fri, Jan 23, 2004 at 02:19:02AM +0100, Szakacsits Szabolcs wrote: 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? Yes. It might be a bit confusing, but I don't think this is a good reason not to include the patch. 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. This is one of my favourite stories! Parted's algorithm works like this: (1) user requests to resize to [X, Y] (where X = start, Y = end) (2) Parted requests from the file system code the resize constraint. This is a fairly simple data structure containing min/max size, and congruences for alignment. For example, if the blocksize is 4k, and the resizer can only add/remove to the start in units of 4k, then the alignment constraint on the start might look like: X = 1 sector (mod 8 sectors) (3) Parted asks the partition code to find the closest permissible match to [X, Y] that simultaneously matches the file system constraint (passed as a parameter), and the partition table constraints. Eg: the msdos code might add this constraint for a logical partition (cylinder crap, needs to be on the second head): X = 1 (mod 63 sectors) The partition table code uses ped_constraint_solve() and ped_constraint_intersect(). The PedConstraint structure has the nice property that the intersection of any pair of PedConstraints can also be represented by a PedConstraint. This is a result of the Chinese Remainder Theorem from Number Theory. (4) if the closest permissible match is a long way from [X, Y], Parted tells the user, and asks them if they want to continue anyway. So, since the resizer's (or mkfs'/whatever) constraint is always respected, there should be no possibility for problems. Before this constraint system was introduced, Parted regularly had major problems with this stuff... the code for doing this stuff was totally unmaintainable. The Chinese Remainder Theorem saves the day! - 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 ... Yeah, GUI design is hard. At least confusion is unlikely to lead to data loss... just wasted time. 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. Good point. - 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 Which file? Where could it be saved? Maybe syslog? 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). Actually, I've found that users really like the personal
Re: [Linux-NTFS-Dev] Re: Re: ntfs resize and gtk frontends
On Fri, Jan 23, 2004 at 09:12:55PM +1100, Andrew Clausen wrote: [ parted in ocaml ] I'm afraid it wouldn't be :) I would like it, if that counts! :)) One thing with O'Caml: would it make it difficult to interface libocamlparted with distro installers? I haven't used O'Caml, but I have enjoyed playing with Haskell a bit, and have heard O'Caml is much less painful for doing IO. Huh, you are all seriously considering this ? phone call with Andrew ... Well, as said, i will try to make a little toy implementation in the next month or so, which would support amiga partition table writing (the one i have experience with), and include both a ocaml text frontend, and a C-binding library which should be as near as possible to libparted, and either parted on top of that, or a smallish C frontend. - most distros ship parted but I don't know any who ships ocaml Debian :) Well, in that case Mandrake also :) Anyway, what dependencies would ocaml add? (some kind of libocaml?) Well, ocaml can be both bytecode and native code. The bytecode is arch independent, and maybe 2-3 times slower than the native code, but i doubt speed is of importance here. As dependency, bytecode stuff needs the ocaml virtual machine, which is 111372 of size. native code can be smaller. There would maybe also be need of some of the ocaml libraries, but not that much. Mostly the Int64 module for 64bit integers, i think. The ocaml-base package contains all the needed stuff for bytecode and is : Package: ocaml-base Depends: libc6 (= 2.3.2.ds1-4), libgdbm3, libncurses5 (= 5.3.20030510-1), tcl8.4 (= 8.4.2), tk8.4 (= 8.4.2), xlibs ( 4.1.0) Many of them would not be really needed in a smallish implementation. all the tcl/tk iand x11 stuff we can remove for example. The size of this package is 149942 though, but it contains all the libraries, and we maybe don't need all that. And naturally, for native code, it would be different, but let's see once i have written something. I see you and Sven agree that the dependencies are small enough for a boot disk. Not sure, but let's give this thing a try. If nothing else it would be an interesting project. Friendly, Sven Luther -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: [Linux-NTFS-Dev] Re: Re: ntfs resize and gtk frontends
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). - 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). But opening a file should work everywhere. Well, 'write' maybe not but most should have at least one read/write directory, probably /tmp. 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. 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'. PS: I just registered an alioth project for Parted. Waiting for approval... Cool :) Cheers, Szaka -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: [Linux-NTFS-Dev] Re: Re: ntfs resize and gtk frontends
* Szakacsits Szabolcs [EMAIL PROTECTED] [040123 12:49]: 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). I think the main problem is no primary partition is left. If hda4 would be free, one could try if modern programm still support having hda4 physically between hda1 and hda2... Hochachtungsvoll, Bernhard R. Link -- The man who trades freedom for security does not deserve nor will he ever receive either. (Benjamin Franklin) -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Re: ntfs resize and gtk frontends
On Wed, Jan 21, 2004 at 10:43:33PM +0100, Szakacsits Szabolcs wrote: On Wed, 21 Jan 2004, Anton Altaparmakov wrote: On Wed, 2004-01-21 at 16:14, Sven Luther wrote: Well, first, i have no intention to do so myself too, but it would be nice if you could give us an estimation of the work needed to move the resize code to libntfs ? It isn't only about just moving the code to libntfs (I answered this some month ago on bug-parted) but Yep, but it is the necessary step to have do the libparted side of things. - make it work with parted - revise parted code - test a lot with parted - make sure it won't break in the future Just see the reiserfs integration, a lot of people destroyed their fs. Why? Reiserfs bugs? Parted bugs? QTParted bugs? I really don't know. I have the impression that it was because libreiserfs behavior changed somehow, and that libparted was adapted only later. In short, a hack could be done in days, a proper integration could take weeks. However nobody has enough/much/any free time. As always. I think some libparted guys where also interested by this. I'm afraid that was me :) But I'm not a libparted guy. There are things I don't like in Parted but I agree it would be very useful for many people. I am interested by your opinion, what is it in parted that you dislike and why ? I personaly am a bit disapointed by the code quality of parted/libparted, and have been toying in doing a reimplmentation in ocaml, with maybe some coq-based prooves of good behavior, and having coq generate the corresponding code afterward. But i lack some time for this, and am not sure an ocaml-based libparted reimplementation would be welcome. Especially in the debian-installer case. BTW, the main problem of parted/libparted right now, is that there is no CVS repository of it, and that the code has been mostly unavailable since may 2003 or so. Friendly, Sven Luther -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Re: ntfs resize and gtk frontends
On Thu, 22 Jan 2004, Sven Luther wrote: On Wed, Jan 21, 2004 at 10:43:33PM +0100, Szakacsits Szabolcs wrote: It isn't only about just moving the code to libntfs (I answered this some month ago on bug-parted) but Yep, but it is the necessary step to have do the libparted side of things. Sure but also what interface libparted needs? We don't have the time to do it twice and checking it out isn't the highest priority now (for me). In high level, resize could tell the constrains and do the resize but for example, it's quite probably in some cases it needs to remount the partition 3 times. Can [lib]parted live with that? I am interested by your opinion, what is it in parted that you dislike and why ? Mostly my lack of knowledge about its internals :) But seriously, - 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. - decimal point usage in sizes is IMHO confusing, useless, ridiculous (partition size is e.g. 315003089.536 bytes). If one needs better resolution then he/she should use smaller units. But see above. - no save/restore partition table functionality. Partitioning is very messy, complicated, a lot of scenarios. When somethings goes wrong (quite frequently if you read/filter many lists/etc) the only you can say sorry, maybe next time (or try testdisk, gpart, etc -- I hear better results than using parted's 'rescue'). - offered choice 'ignore' to the users when it is _nonsense_ and would destroy their data. It does as it were demonstrated several times. - 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. I personaly am a bit disapointed by the code quality of parted/libparted, Would you mind to express? and have been toying in doing a reimplmentation in ocaml, with maybe some coq-based prooves of good behavior, and having coq generate the corresponding code afterward. But i lack some time for this, and am not sure an ocaml-based libparted reimplementation would be welcome. I'm afraid it wouldn't be :) - most distros ship parted but I don't know any who ships ocaml - many people know C thus they might contribute but most doesn't know ocaml and should learn it to do so - you would throw away a lot of hidden knowledge in parted and you should rediscover them the hard way BTW, the main problem of parted/libparted right now, is that there is no CVS repository of it, and that the code has been mostly unavailable since may 2003 or so. Yes and somebody who has the time to maintain it. Szaka -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Re: ntfs resize and gtk frontends
On Thu, Jan 22, 2004 at 04:18:10PM +0100, Szakacsits Szabolcs wrote:
On Thu, 22 Jan 2004, Sven Luther wrote:
On Wed, Jan 21, 2004 at 10:43:33PM +0100, Szakacsits Szabolcs wrote:
It isn't only about just moving the code to libntfs (I answered this some
month ago on bug-parted) but
Yep, but it is the necessary step to have do the libparted side of
things.
Sure but also what interface libparted needs? We don't have the time to do
it twice and checking it out isn't the highest priority now (for me).
Well, you could use the libparted filesystem handling as interface.
struct _PedFileSystemOps {
PedGeometry* (*probe) (PedGeometry* geom);
int (*clobber) (PedGeometry* geom);
PedFileSystem* (*open) (PedGeometry* geom);
PedFileSystem* (*create) (PedGeometry* geom, PedTimer* timer);
int (*close) (PedFileSystem* fs);
int (*check) (PedFileSystem* fs, PedTimer* timer);
PedFileSystem* (*copy) (const PedFileSystem* fs, PedGeometry* geom,
PedTimer* timer);
int (*resize) (PedFileSystem* fs, PedGeometry* geom, PedTimer* timer);
PedConstraint* (*get_create_constraint) (const PedDevice* dev);
PedConstraint* (*get_resize_constraint) (const PedFileSystem* fs);
PedConstraint* (*get_copy_constraint) (const PedFileSystem* fs,
const PedDevice* dev);
};
Look at the include/parted directory in the parted source for everything
you need.
In high level, resize could tell the constrains and do the resize but
for example, it's quite probably in some cases it needs to remount
the partition 3 times. Can [lib]parted live with that?
I know nothing about ntfs, but i suppose it is somewhat silly to have to
mount the partition while resizing it.
I am interested by your opinion, what is it in parted that you dislike
and why ?
Mostly my lack of knowledge about its internals :) But seriously,
- 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.
Notice that this is a critic of the parted program, it doesn't apply to
the underlying libparted, which is what matters. Libparted uses
geometries which are of the start/end/size kind of information, where
all three of those are 64bit integers.
- decimal point usage in sizes is IMHO confusing, useless, ridiculous
(partition size is e.g. 315003089.536 bytes). If one needs better
resolution then he/she should use smaller units. But see above.
Mmm, i don't know about this.
- no save/restore partition table functionality. Partitioning is very
messy, complicated, a lot of scenarios. When somethings goes wrong
(quite frequently if you read/filter many lists/etc) the only you can
say sorry, maybe next time (or try testdisk, gpart, etc -- I hear
better results than using parted's 'rescue').
Ok, i agree with this, but it could easily be implemented.
That said, only the parted programs commits after each change, it is
perfectly possible to have a libparted using program which does all the
changes in the in-mem copy of the partition table, and do everything at
once once you are happy with it. Doing filesystem creation is the
problematic part, but i guess even that could be queued.
- offered choice 'ignore' to the users when it is _nonsense_ and would
destroy their data. It does as it were demonstrated several times.
Again, a parted interface problem, not really related to libparted. This
could easily be done in any graphical tool using libparted or something.
- 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.
This is a real problem, but again not one of libparted per see, more one
linked to the fact that there is no open CVS or whatever repository.
This has to be solved soon, or parted will be forked or something.
I personaly am a bit disapointed by the code quality of
parted/libparted,
Would you mind to express?
Just a general impression, and the lack of accessible CVS repository
doesn't help. The parted UI often dies for no reason at all, there are
some garbage asserts in there which are leftover and makes thing fail
horribly in some cases, and so on. I think the main problem is that
there is need of more active maintaining and some cleanup of the
internal stuff.
and have been toying in doing a reimplmentation in ocaml, with maybe
some coq-based prooves of good behavior, and having coq generate the
corresponding code afterward. But i lack some time for this, and am
not sure an ocaml-based libparted reimplementation would be welcome.
I'm afraid it wouldn't be :)
- most distros
Re: Re: ntfs resize and gtk frontends
On Thu, 22 Jan 2004, Sven Luther wrote: I know nothing about ntfs, but i suppose it is somewhat silly to have to mount the partition while resizing it. It's called online resizing. XFS, JFS, reiserfs support online expansion. However NTFS resizing is offline and it's indeed unwise to have the partition mounted, actually so much that resizing isn't possible if the partition is found to be mounted. The source of confusion is the somewhat misnomer naming. Opening a device is done in libntfs by ntfs_mount(). In short the device/partition must be open/closed three times during shrinkage in some cases. I am interested by your opinion, what is it in parted that you dislike Note, you asked about parted, not libparted so this is why I wrote about parted. Knowing where things are in sector level is very important occasionally. Notice that this is a critic of the parted program, it doesn't apply to the underlying libparted, which is what matters. Of course, but when you have to investigate user issues you can't say them just hack libparted. Libparted uses geometries which are of the start/end/size kind of information, where all three of those are 64bit integers. But this geometry isn't the disk C/H/S geometry however start/end/size are in sectors, right? This is a real problem, but again not one of libparted per see, more one linked to the fact that there is no open CVS or whatever repository. This has to be solved soon, or parted will be forked or something. E.g. somebody (you? :) could help out Andrew and if he still won't have time then incrementally take over maintainership, or something :) Just a general impression, and the lack of accessible CVS repository doesn't help. The parted UI often dies for no reason at all, there are some garbage asserts in there which are leftover and makes thing fail horribly in some cases, and so on. I think the main problem is that there is need of more active maintaining and some cleanup of the internal stuff. This is my impression also. I would _do_ love to recommend parted to people because doing an ntfsresize + Parted's 'resize' looks much easier, safer than doing 14 steps with fdisk. But fdisk works (altough that one also has its own slight problems :-/). The objection i would have, would be more that you would have to bind in the ocaml runtime and virtual machine, which may be problematic in the small size initrd case of installers, I didn't mention this because I thought it's not true anymore. Cheers, Szaka -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Re: ntfs resize and gtk frontends
On Thu, Jan 22, 2004 at 08:16:32PM +0100, Szakacsits Szabolcs wrote: On Thu, 22 Jan 2004, Sven Luther wrote: I know nothing about ntfs, but i suppose it is somewhat silly to have to mount the partition while resizing it. It's called online resizing. XFS, JFS, reiserfs support online expansion. However NTFS resizing is offline and it's indeed unwise to have the partition mounted, actually so much that resizing isn't possible if the partition is found to be mounted. The source of confusion is the somewhat misnomer naming. Opening a device is done in libntfs by ntfs_mount(). In short the device/partition must be open/closed three times during shrinkage in some cases. Ok. I guess there should be no problem with this. I am interested by your opinion, what is it in parted that you dislike Note, you asked about parted, not libparted so this is why I wrote about parted. My fault, but the main point is adding support for ntfs in libparted. parted itself knows nothing about filesystems or partition table types. Knowing where things are in sector level is very important occasionally. Notice that this is a critic of the parted program, it doesn't apply to the underlying libparted, which is what matters. Of course, but when you have to investigate user issues you can't say them just hack libparted. No, but you could provide an enhanced frontend. Maybe already do so, there are at least three tools in debian-installer, and various graphical frontends, qtparted among them. Libparted uses geometries which are of the start/end/size kind of information, where all three of those are 64bit integers. But this geometry isn't the disk C/H/S geometry however start/end/size are in sectors, right? No, plain sector number in 64 bit integers. Defaults to 512K sectors though. This is a real problem, but again not one of libparted per see, more one linked to the fact that there is no open CVS or whatever repository. This has to be solved soon, or parted will be forked or something. E.g. somebody (you? :) could help out Andrew and if he still won't have time then incrementally take over maintainership, or something :) Yeah, but first the necessary stuff needs to be done to reopen the savanah CVS. I think Andrew is on this, but due to the savanah intrusion, new projects and such where postponed to end of january. Just a general impression, and the lack of accessible CVS repository doesn't help. The parted UI often dies for no reason at all, there are some garbage asserts in there which are leftover and makes thing fail horribly in some cases, and so on. I think the main problem is that there is need of more active maintaining and some cleanup of the internal stuff. This is my impression also. I would _do_ love to recommend parted to people because doing an ntfsresize + Parted's 'resize' looks much easier, safer than doing 14 steps with fdisk. But fdisk works (altough that one also has its own slight problems :-/). Yeah. The objection i would have, would be more that you would have to bind in the ocaml runtime and virtual machine, which may be problematic in the small size initrd case of installers, I didn't mention this because I thought it's not true anymore. Ah, so you are familiar with ocaml, nice. Friendly, Sven Luther -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Re: ntfs resize and gtk frontends
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) Besides, this usually isn't a problem, because things get rounded in a big way for alignment stuff. - decimal point usage in sizes is IMHO confusing, useless, ridiculous (partition size is e.g. 315003089.536 bytes). If one needs better resolution then he/she should use smaller units. But see above. Agreed. - no save/restore partition table functionality. Partitioning is very messy, complicated, a lot of scenarios. When somethings goes wrong (quite frequently if you read/filter many lists/etc) the only you can say sorry, maybe next time (or try testdisk, gpart, etc -- I hear better results than using parted's 'rescue'). qtparted allows you to commit. I think this is a better solution (but both features are good) - offered choice 'ignore' to the users when it is _nonsense_ and would destroy their data. It does as it were demonstrated several times. There are plenty of times when it isn't nonsense, but you have convinced me we should be more conservative. - 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 think it's best to minimize the time users have to spend to report a bug - otherwise they won't bother. and have been toying in doing a reimplmentation in ocaml, with maybe some coq-based prooves of good behavior, and having coq generate the corresponding code afterward. But i lack some time for this, and am not sure an ocaml-based libparted reimplementation would be welcome. 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 :) - many people know C thus they might contribute but most doesn't know ocaml and should learn it to do so This is important. - you would throw away a lot of hidden knowledge in parted and you should rediscover them the hard way I wouldn't mind watching over it. (This is less time-consuming than maintenance) Cheers, Andrew -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Re: ntfs resize and gtk frontends
On Thu, Jan 22, 2004 at 08:16:32PM +0100, Szakacsits Szabolcs wrote: This is a real problem, but again not one of libparted per see, more one linked to the fact that there is no open CVS or whatever repository. This has to be solved soon, or parted will be forked or something. E.g. somebody (you? :) could help out Andrew and if he still won't have time then incrementally take over maintainership, or something :) I have no objection to this. The only reason I have a priviledged position is because the way uploads to ftp.gnu.org used to work. I can add Sven's GPG signature, for after when they apply the md5sums. Sven: can you give me your GPG key and phone number? Cheers, Andrew -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Re: ntfs resize and gtk frontends
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 :) Cheers, Szaka -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Re: ntfs resize and gtk frontends
On Mon, Jan 19, 2004 at 02:27:12PM -0600, Steve Langasek wrote: On Mon, Jan 19, 2004 at 09:24:06PM +0100, Sven Luther wrote: NTFS write support at the kernel level is not very well-tested, but resizing partitions with the userspace tools is something that gets used fairly frequently. So, there is NTFS resizing user space tool ? Anything that is packaged in debian and we can use in d-i ? Yes, it's the tool named ntfsresize that the original poster was referring to, and it's found in the ntfstools package. But is not in any way related to the libntfs library ? Package: ntfstools Source: linux-ntfs Version: 1.8.0-2 Depends: libc6 (= 2.3.2.ds1-4), libntfs5 (= 1.8.0) I haven't looked at the source to know which pieces are exposed through the library or not. I say this, because on the parted mailing list, less than a week ago, it was claimed that libntfs didn't support resizing. Still, i wonder what the use of many outside library would mean to libparted and its use in debian-installer, where size matters. libntfs doesn't support resizing at present, that is correct. However, ntfsresize uses functionality from libntfs and cannot work without it. Hope this clears up any confusion. (-: Best regards, Anton -- Anton Altaparmakov aia21 at cam.ac.uk (replace at with @) Unix Support, Computing Service, University of Cambridge, CB2 3QH, UK Linux NTFS maintainer / IRC: #ntfs on irc.freenode.net WWW: http://linux-ntfs.sf.net/ http://www-stu.christs.cam.ac.uk/~aia21/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Re: ntfs resize and gtk frontends
On Wed, Jan 21, 2004 at 03:15:35PM +, Anton Altaparmakov wrote: On Mon, Jan 19, 2004 at 02:27:12PM -0600, Steve Langasek wrote: On Mon, Jan 19, 2004 at 09:24:06PM +0100, Sven Luther wrote: NTFS write support at the kernel level is not very well-tested, but resizing partitions with the userspace tools is something that gets used fairly frequently. So, there is NTFS resizing user space tool ? Anything that is packaged in debian and we can use in d-i ? Yes, it's the tool named ntfsresize that the original poster was referring to, and it's found in the ntfstools package. But is not in any way related to the libntfs library ? Package: ntfstools Source: linux-ntfs Version: 1.8.0-2 Depends: libc6 (= 2.3.2.ds1-4), libntfs5 (= 1.8.0) I haven't looked at the source to know which pieces are exposed through the library or not. I say this, because on the parted mailing list, less than a week ago, it was claimed that libntfs didn't support resizing. Still, i wonder what the use of many outside library would mean to libparted and its use in debian-installer, where size matters. libntfs doesn't support resizing at present, that is correct. However, ntfsresize uses functionality from libntfs and cannot work without it. Any chance of the resizing fucntionality of ntfsresize making it to libntfs ? Friendly, Sven Luther -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Re: ntfs resize and gtk frontends
On Wed, 2004-01-21 at 15:23, Sven Luther wrote: On Wed, Jan 21, 2004 at 03:15:35PM +, Anton Altaparmakov wrote: On Mon, Jan 19, 2004 at 02:27:12PM -0600, Steve Langasek wrote: On Mon, Jan 19, 2004 at 09:24:06PM +0100, Sven Luther wrote: NTFS write support at the kernel level is not very well-tested, but resizing partitions with the userspace tools is something that gets used fairly frequently. So, there is NTFS resizing user space tool ? Anything that is packaged in debian and we can use in d-i ? Yes, it's the tool named ntfsresize that the original poster was referring to, and it's found in the ntfstools package. But is not in any way related to the libntfs library ? Package: ntfstools Source: linux-ntfs Version: 1.8.0-2 Depends: libc6 (= 2.3.2.ds1-4), libntfs5 (= 1.8.0) I haven't looked at the source to know which pieces are exposed through the library or not. I say this, because on the parted mailing list, less than a week ago, it was claimed that libntfs didn't support resizing. Still, i wonder what the use of many outside library would mean to libparted and its use in debian-installer, where size matters. libntfs doesn't support resizing at present, that is correct. However, ntfsresize uses functionality from libntfs and cannot work without it. Any chance of the resizing fucntionality of ntfsresize making it to libntfs ? Yes, of course, but that (at least to me) is very low priority so don't expect it anytime soon... Sorry... Best regards, Anton -- Anton Altaparmakov aia21 at cam.ac.uk (replace at with @) Unix Support, Computing Service, University of Cambridge, CB2 3QH, UK Linux NTFS maintainer / IRC: #ntfs on irc.freenode.net WWW: http://linux-ntfs.sf.net/ http://www-stu.christs.cam.ac.uk/~aia21/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Re: ntfs resize and gtk frontends
On Wed, Jan 21, 2004 at 03:25:28PM +, Anton Altaparmakov wrote: On Wed, 2004-01-21 at 15:23, Sven Luther wrote: On Wed, Jan 21, 2004 at 03:15:35PM +, Anton Altaparmakov wrote: On Mon, Jan 19, 2004 at 02:27:12PM -0600, Steve Langasek wrote: On Mon, Jan 19, 2004 at 09:24:06PM +0100, Sven Luther wrote: NTFS write support at the kernel level is not very well-tested, but resizing partitions with the userspace tools is something that gets used fairly frequently. So, there is NTFS resizing user space tool ? Anything that is packaged in debian and we can use in d-i ? Yes, it's the tool named ntfsresize that the original poster was referring to, and it's found in the ntfstools package. But is not in any way related to the libntfs library ? Package: ntfstools Source: linux-ntfs Version: 1.8.0-2 Depends: libc6 (= 2.3.2.ds1-4), libntfs5 (= 1.8.0) I haven't looked at the source to know which pieces are exposed through the library or not. I say this, because on the parted mailing list, less than a week ago, it was claimed that libntfs didn't support resizing. Still, i wonder what the use of many outside library would mean to libparted and its use in debian-installer, where size matters. libntfs doesn't support resizing at present, that is correct. However, ntfsresize uses functionality from libntfs and cannot work without it. Any chance of the resizing fucntionality of ntfsresize making it to libntfs ? Yes, of course, but that (at least to me) is very low priority so don't expect it anytime soon... Sorry... Well, first, i have no intention to do so myself too, but it would be nice if you could give us an estimation of the work needed to move the resize code to libntfs ? I think some libparted guys where also interested by this. Friendly, Sven Luther -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Re: ntfs resize and gtk frontends
On Wed, 2004-01-21 at 16:14, Sven Luther wrote: On Wed, Jan 21, 2004 at 03:25:28PM +, Anton Altaparmakov wrote: On Wed, 2004-01-21 at 15:23, Sven Luther wrote: On Wed, Jan 21, 2004 at 03:15:35PM +, Anton Altaparmakov wrote: On Mon, Jan 19, 2004 at 02:27:12PM -0600, Steve Langasek wrote: On Mon, Jan 19, 2004 at 09:24:06PM +0100, Sven Luther wrote: NTFS write support at the kernel level is not very well-tested, but resizing partitions with the userspace tools is something that gets used fairly frequently. So, there is NTFS resizing user space tool ? Anything that is packaged in debian and we can use in d-i ? Yes, it's the tool named ntfsresize that the original poster was referring to, and it's found in the ntfstools package. But is not in any way related to the libntfs library ? Package: ntfstools Source: linux-ntfs Version: 1.8.0-2 Depends: libc6 (= 2.3.2.ds1-4), libntfs5 (= 1.8.0) I haven't looked at the source to know which pieces are exposed through the library or not. I say this, because on the parted mailing list, less than a week ago, it was claimed that libntfs didn't support resizing. Still, i wonder what the use of many outside library would mean to libparted and its use in debian-installer, where size matters. libntfs doesn't support resizing at present, that is correct. However, ntfsresize uses functionality from libntfs and cannot work without it. Any chance of the resizing fucntionality of ntfsresize making it to libntfs ? Yes, of course, but that (at least to me) is very low priority so don't expect it anytime soon... Sorry... Well, first, i have no intention to do so myself too, but it would be nice if you could give us an estimation of the work needed to move the resize code to libntfs ? I think some libparted guys where also interested by this. I am afraid I have no idea as I haven't really looked at the ntfsresize code. I am CC:-ing Szaka who wrote and maintains ntfsresize in the hope that he will comments. Best regards, Anton -- Anton Altaparmakov aia21 at cam.ac.uk (replace at with @) Unix Support, Computing Service, University of Cambridge, CB2 3QH, UK Linux NTFS maintainer / IRC: #ntfs on irc.freenode.net WWW: http://linux-ntfs.sf.net/ http://www-stu.christs.cam.ac.uk/~aia21/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Re: ntfs resize and gtk frontends
* Anton Altaparmakov [EMAIL PROTECTED] [2004-01-21 16:25]: I am afraid I have no idea as I haven't really looked at the ntfsresize code. I am CC:-ing Szaka who wrote and maintains ntfsresize in the hope that he will comments. BTW, it would be really excellent to get this merged into libparted. (I understand this might be low or no priority for you at all, but many people would benefit from it.) Anton Altaparmakov aia21 at cam.ac.uk (replace at with @) I'm msm34. ;) -- Martin Michlmayr [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Re: Re: ntfs resize and gtk frontends
Flatcap are working on insert the ntfs tools (ntfsresize is a part of it) in the usable library libntfs but need help. You can find it on irc.freenode.net #ntfs channel or at [EMAIL PROTECTED] address. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Re: ntfs resize and gtk frontends
On Wed, 21 Jan 2004, Anton Altaparmakov wrote: On Wed, 2004-01-21 at 16:14, Sven Luther wrote: Well, first, i have no intention to do so myself too, but it would be nice if you could give us an estimation of the work needed to move the resize code to libntfs ? It isn't only about just moving the code to libntfs (I answered this some month ago on bug-parted) but - make it work with parted - revise parted code - test a lot with parted - make sure it won't break in the future Just see the reiserfs integration, a lot of people destroyed their fs. Why? Reiserfs bugs? Parted bugs? QTParted bugs? I really don't know. In short, a hack could be done in days, a proper integration could take weeks. However nobody has enough/much/any free time. I think some libparted guys where also interested by this. I'm afraid that was me :) But I'm not a libparted guy. There are things I don't like in Parted but I agree it would be very useful for many people. I am afraid I have no idea as I haven't really looked at the ntfsresize code. I am CC:-ing Szaka who wrote and maintains ntfsresize in the hope that he will comments. I commented it in a different thread. If my emails don't get to the list then please somebody forward them, thanks! Cheers, Szaka -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Re: ntfs resize and gtk frontends
On Wed, 21 Jan 2004, Martin Michlmayr wrote: BTW, it would be really excellent to get this merged into libparted. (I understand this might be low or no priority for you at all, but many people would benefit from it.) I don't doubt. But the need for full relocation support is _MUCH_ higher. First things first ;) Of course if one wants to work on it he/she is very well welcomed :) Cheers, Szaka -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: ntfs resize and gtk frontends
On Mon, Jan 19, 2004 at 05:52:53PM -0600, Steve Langasek wrote: On Mon, Jan 19, 2004 at 10:02:14PM +0100, Sven Luther wrote: But is not in any way related to the libntfs library ? Package: ntfstools Source: linux-ntfs Version: 1.8.0-2 Depends: libc6 (= 2.3.2.ds1-4), libntfs5 (= 1.8.0) I haven't looked at the source to know which pieces are exposed through the library or not. I say this, because on the parted mailing list, less than a week ago, it was claimed that libntfs didn't support resizing. That's entirely possible, but there is code in the same source distribution to support it, regardless of whether it's currently part of the library. Still, i wonder what the use of many outside library would mean to libparted and its use in debian-installer, where size matters. Depending on the robustness of the ntfsresize commandline interface, perhaps this can be included as a lower-priority udeb that libparted (partman?) can interface with iff it's available? Yeah, but it would be better if it was available directly trough libparted, i think. Friendly, Sven Luther -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: ntfs resize and gtk frontends
On Mon, Jan 19, 2004 at 10:02:14PM +0100, Sven Luther wrote: Still, i wonder what the use of many outside library would mean to libparted and its use in debian-installer, where size matters. It is not necessary for libparted to depend strongly on libntfs but the same way as on libreiserfs. When the libreiserfs is present then parted uses it and provides support to resize the reiser file system. However parted doesn't depend on libreiserfs. This means that libntfs can be packaged in udeb that will be unpacked only when the memory is enough (or rather only when the user requests full support for ntfs). On 19.I.2004 at 17:52 Steve Langasek wrote: Depending on the robustness of the ntfsresize commandline interface, perhaps this can be included as a lower-priority udeb that libparted (partman?) can interface with iff it's available? This is also possible. Anton Zinoviev -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: ntfs resize and gtk frontends
* Fabri [EMAIL PROTECTED] [2004-01-19 18:52]: | Any plan on support ntfs resize in the new debian installer? | | Any update or plan on gtk frontends to d-i and an integration with | bootsplash (bootsplash packages are now on debian mentors repos)? any plan to help us writing a gtk frontend? or integration of ntfs resizing support? :-) -- Thorsten Sauter [EMAIL PROTECTED] (Is there life after /sbin/halt -p?) -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: ntfs resize and gtk frontends
On Mon, Jan 19, 2004 at 06:52:50PM +0100, Fabri wrote: Any plan on support ntfs resize in the new debian installer? There has been some discussion in the parted mailing list about linking libparted with libntfs and provide advanced ntfs functionality. That said, it seems that libntfs doesn't provide resizing functionality, and that ntfs write support in the linux kernel is also a bit shaggy still, so i wouldn't count on it too much. Friendly, Sven Luther -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: ntfs resize and gtk frontends
On Mon, Jan 19, 2004 at 01:29:01PM -0600, Steve Langasek wrote: On Mon, Jan 19, 2004 at 07:22:13PM +0100, Sven Luther wrote: On Mon, Jan 19, 2004 at 06:52:50PM +0100, Fabri wrote: Any plan on support ntfs resize in the new debian installer? There has been some discussion in the parted mailing list about linking libparted with libntfs and provide advanced ntfs functionality. That said, it seems that libntfs doesn't provide resizing functionality, and that ntfs write support in the linux kernel is also a bit shaggy still, so i wouldn't count on it too much. NTFS write support at the kernel level is not very well-tested, but resizing partitions with the userspace tools is something that gets used fairly frequently. So, there is NTFS resizing user space tool ? Anything that is packaged in debian and we can use in d-i ? Friendly, Sven Luther -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: ntfs resize and gtk frontends
On Mon, Jan 19, 2004 at 01:37:31PM -0600, Steve Langasek wrote: On Mon, Jan 19, 2004 at 08:33:42PM +0100, Sven Luther wrote: On Mon, Jan 19, 2004 at 01:29:01PM -0600, Steve Langasek wrote: On Mon, Jan 19, 2004 at 07:22:13PM +0100, Sven Luther wrote: On Mon, Jan 19, 2004 at 06:52:50PM +0100, Fabri wrote: Any plan on support ntfs resize in the new debian installer? There has been some discussion in the parted mailing list about linking libparted with libntfs and provide advanced ntfs functionality. That said, it seems that libntfs doesn't provide resizing functionality, and that ntfs write support in the linux kernel is also a bit shaggy still, so i wouldn't count on it too much. NTFS write support at the kernel level is not very well-tested, but resizing partitions with the userspace tools is something that gets used fairly frequently. So, there is NTFS resizing user space tool ? Anything that is packaged in debian and we can use in d-i ? Yes, it's the tool named ntfsresize that the original poster was referring to, and it's found in the ntfstools package. But is not in any way related to the libntfs library ? Friendly, Sven Luther -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: ntfs resize and gtk frontends
On Mon, Jan 19, 2004 at 02:27:12PM -0600, Steve Langasek wrote: On Mon, Jan 19, 2004 at 09:24:06PM +0100, Sven Luther wrote: NTFS write support at the kernel level is not very well-tested, but resizing partitions with the userspace tools is something that gets used fairly frequently. So, there is NTFS resizing user space tool ? Anything that is packaged in debian and we can use in d-i ? Yes, it's the tool named ntfsresize that the original poster was referring to, and it's found in the ntfstools package. But is not in any way related to the libntfs library ? Package: ntfstools Source: linux-ntfs Version: 1.8.0-2 Depends: libc6 (= 2.3.2.ds1-4), libntfs5 (= 1.8.0) I haven't looked at the source to know which pieces are exposed through the library or not. I say this, because on the parted mailing list, less than a week ago, it was claimed that libntfs didn't support resizing. Still, i wonder what the use of many outside library would mean to libparted and its use in debian-installer, where size matters. Friendly, Sven Luther -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: ntfs resize and gtk frontends
On Mon Jan 19, 2004 at 09:24:06PM +0100, Sven Luther wrote: Yes, it's the tool named ntfsresize that the original poster was referring to, and it's found in the ntfstools package. But is not in any way related to the libntfs library ? $ dlocate /usr/sbin/ntfsresize ntfstools: /usr/sbin/ntfsresize $ ldd /usr/sbin/ntfsresize libntfs.so.4 = /usr/lib/libntfs.so.4 (0x40028000) libc.so.6 = /lib/libc.so.6 (0x40038000) /lib/ld-linux.so.2 = /lib/ld-linux.so.2 (0x4000) $ dlocate /usr/lib/libntfs.so.4 libntfs4: /usr/lib/libntfs.so.4.0.0 libntfs4: /usr/lib/libntfs.so.4 -Erik -- Erik B. Andersen http://codepoet-consulting.com/ --This message was written using 73% post-consumer electrons-- -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: ntfs resize and gtk frontends
On Mon, Jan 19, 2004 at 09:24:06PM +0100, Sven Luther wrote: NTFS write support at the kernel level is not very well-tested, but resizing partitions with the userspace tools is something that gets used fairly frequently. So, there is NTFS resizing user space tool ? Anything that is packaged in debian and we can use in d-i ? Yes, it's the tool named ntfsresize that the original poster was referring to, and it's found in the ntfstools package. But is not in any way related to the libntfs library ? Package: ntfstools Source: linux-ntfs Version: 1.8.0-2 Depends: libc6 (= 2.3.2.ds1-4), libntfs5 (= 1.8.0) I haven't looked at the source to know which pieces are exposed through the library or not. -- Steve Langasek postmodern programmer pgp0.pgp Description: PGP signature
Re: ntfs resize and gtk frontends
On Mon, Jan 19, 2004 at 08:02:16PM +0100, Geert Stappers wrote: On Mon, Jan 19, 2004 at 07:41:34PM +0100, Thorsten Sauter wrote: * Fabri [EMAIL PROTECTED] [2004-01-19 18:52]: Any plan on support ntfs resize in the new debian installer? Any update or plan on gtk frontends to d-i and an integration with bootsplash (bootsplash packages are now on debian mentors repos)? any plan to help us writing a gtk frontend? or integration of ntfs resizing support? :-) I didn't understood the original poster neither. It could be indeed an offer for help and as always: help is welcome. About the gtk frontend: There wheren't any posting on the subject here, so there is probably most help needed About the NTFS resize: There was recently a post with 'I worked for me', so there can people help with a verify plus report Here's what I've done when there was a need for resizing an ntfs partionion, while installing skolelinux: boot with the skolelinux CD, but stopped before autopartkit is run. insert a cd with a static version of ntfsresize from http://mlf.linux.rulez.org/mlf/ezaz/ntfsresize.html#static, and ran ntfsresize, tvice, first to make room for the new partitions, then after using cfdisk to resize, I've run ntfsresize a second time to use the whole partition. I've done this 5 or 6 times, and only failed once, when I made the partition to small (smaler than the resized size obvisly) adding ntfsresize in the installer image, would be helpfull even if it has to be run from the command line. -- Finn-Arne Johansen [EMAIL PROTECTED] http://bzz.no/?page=finnarne Registered Linux user #86307 (http://counter.li.org) -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: ntfs resize and gtk frontends
On Mon, Jan 19, 2004 at 10:02:14PM +0100, Sven Luther wrote: But is not in any way related to the libntfs library ? Package: ntfstools Source: linux-ntfs Version: 1.8.0-2 Depends: libc6 (= 2.3.2.ds1-4), libntfs5 (= 1.8.0) I haven't looked at the source to know which pieces are exposed through the library or not. I say this, because on the parted mailing list, less than a week ago, it was claimed that libntfs didn't support resizing. That's entirely possible, but there is code in the same source distribution to support it, regardless of whether it's currently part of the library. Still, i wonder what the use of many outside library would mean to libparted and its use in debian-installer, where size matters. Depending on the robustness of the ntfsresize commandline interface, perhaps this can be included as a lower-priority udeb that libparted (partman?) can interface with iff it's available? -- Steve Langasek postmodern programmer pgp0.pgp Description: PGP signature
