|
From: Richard R. <nt...@fl...> - 2003-11-15 11:01:58
|
Hi Szaka, Reading this through I think I should have started with: "I have a dream." > [I got this in private, but I answer to the list Given the content, I sent it to you to give you a chance to reply > others maybe be also interested Definitely. I did intend most of the content for the list. > > > changes to ... ntfsresize. > > Please don't. Not as it stands. > But you didn't even see it :))) But I have seen the rest of your code. > > For the last year or so, I've been trying to sort out all the code. > That's appreciated a lot, believe me. Then give some feedback. I know I'm not great at this either. Most of it is self-imposed, but I feel like I'm running the project single-handedly. > Ian Jackson wrote earlier at > the stuff to implement the force, help, verbose, quiet, and version options, I looked through the code and ripped out any any duplication, so now the programs are built from a toolkit. The only code you need to think about is the ntfs bit. > Are there any plans to rationalise this, or > should I just follow the example of the other tools ? He should go with the flow. > Counting the command line parsing errors What? I do "err++", just out of convenience. I don't actually use the value for anything. It might be useful to someone some day. I don't break at that point because that gives you the ability to find all the errors on the command line, not just the first. > is a waste of time (to implement and maintain). Again, what? I wrote the original ntfs getopt code. To cut, paste and tweak it is trivial. What are you suggesting? > be the interface for the functionality when the utils move to the library? No, they need a strict binary interface. They may need an options struct, because there may be a lot of things to control. > I don't think so. At least I've never planned for those I wrote. It shows. Having written software professionally for a long time, I have a good eye for code reuse. I should have complained earlier, but you've been writing a useful tool, that I didn't have time for myself. But... To reuse any code from resize is a major undertaking. In resize you want to run chkdsk. Something a lot of other tools would want to do. But the code is heavily intertwined with other stuff. > Not for ntfsresize. I plan ntfsresize to be only a very short reference > impementation how to use the resize functionality when the core > functionality will be moved to the library. Oh great. You'll have to rewrite it from scratch. A quick check reveals 72 exit statements - they'll all have to go and be replaced with return values. That is some major reconstruction. That means restarting the testing from scratch, too. > ntfsresize, as a standalone application > is a very fragile and inefficient interface to partitioning programs. But that's the only option you've given them. Will you have the time to rewrite it? > Working on the options parsing won't make it better. I haven't done it to make people's programs better, I've done it to save them time, so *they* can make their programs better. > I don't understand why you put a lot of functions to the separate utils.c file That's just laziness. It's far quicker, and easier, to rebuild utils.c than the libs. Most of utils.c can be moved into the .so except for one problem. We still don't have a strategy for error handling. Anton and I have discussed a few ideas (in a pub, so there isn't a log), but that's as far as it got. > > ntfsresize contains some useful features, but they are wasted as they > > are. > > For others, yes wasted. But it's open source and anybody can move those > features to a shared library, if needs them. I wouldn't bother. > > We currently have separate implementations of cluster find > 1) different tools might need different functionality. Yes, and thing need breaking down into atomic units that can be reused. > What I needed is nobody implemented yet But you must ask yourself, "could this be useful to someone else?". And then code it accordingly. That's what's missing in your code. > and apparently you test with NT4 what almost nobody uses anymore: Yes. I do most of my work against NT4. It's convenient to have a version of Windows that runs in 16MB of memory (in vmware). 99% of NTFS hasn't changed since then, so for what we're doing it's an adequate test for development processes. I didn't say that I don't test against other versions. I have vms for NT, 2K, XP, 2K3. Happy now? > 2) In the early stage, I don't see parallel minor implementations a > big drawback. I agree. > > I haven't written these tools to undermine you, > No need for excuse I've never thought that :) Good, I'm glad to hear that. > At least the ntldr issue made me think :) :-) > Are there plans for cooperation with Parted? > Yes ... depends on users' interest Yeah, we all have limited time. > So far there were less than 10 such requests compared to the several > _orders_ bigger "please support fragmented volumes". You didn't think that defrag would be better as a separate tool? > > In this method, I'm starting ntfsck. It will start with the bitmap > > checking from resize. > > Cool. I wrote about this here: > - design, write an ntfs_walk_clusters_by_<inode|mft>() function. > what at least ntfsresize, ntfsclone, ntfsmeta already have ... Now that's sounding a bit better. Speaking of which, where's the source to "ntfsmeta"? I've seen you give out the binary plenty of times. > Please also consider it must be possible to have the callbacks linked at > each stages. > > ntfsresize is ... a maze of ... exit statements. > That's a very important implementation issue. That makes the code unusable to others. > It makes sure when something > would go unexpected, ntfsresize quits immediately. No even cleanup! Hmm... > > There are three ways a program call our code ... shared lib ntfsapps.so. > Aha! Now I understand why you're doing some of the things that didn't make > any sense before. Aha, indeed. I have thought through all this at quite some depth :- > However I think ntfsapps.so doesn't sound very good. Maybe one lib between > the two levels, Yes. The libntfs is way too low-level for most people to consider using. > if you don't want too feature rich libntfs (already 65 kB > but I think a _LOT OF_ duplicated code could be removed from there also). Quite possibly. I haven't focused on that yet. > Of course having more libs will result more problems No doubt. But if the code is broken into smaller testable units, what won't be so much of a problem. > > Our tools are useful, already, but there is so much room for improvement. > my only request is, please regard the working functionality. Of course. I'm never going to replace anything functional without a lot of testing. Cheers, Rich |
