|
From: Richard R. <nt...@fl...> - 2003-10-29 18:33:48
|
Hi all, I've just hacked together "ntfsmove", a precursor to ntfsdefrag. I wouldn't recommend using it yet, since it's not got any error checking. However, if you were to use it, you might see results like: http://flatcap.org/ntfs/move_before.png http://flatcap.org/ntfs/move_after.png This is the result of running ntfsmove on 162 files. NT didn't notice and md5sums on all the files came out correctly. I've committed all the source to the ntfsprogs-devel bitkeeper repository and made available a snapshot of the source. bk clone bk://linux-ntfs.bkbits.net/ntfsprogs-devel http://linux-ntfs.sf.net/snapshots/ntfsprogs-devel-200310291927.tar.bz2 Cheers, FlatCap (Rich) nt...@fl... WWW: http://linux-ntfs.sourceforge.net IRC: #ntfs on irc.freenode.net |
|
From: Szakacsits S. <sz...@si...> - 2003-11-12 20:29:00
|
Hi, On Wed, 29 Oct 2003, Richard Russon wrote: > I've just hacked together "ntfsmove", a precursor to ntfsdefrag. I think you could even call it ntfsdefrag already. The name "ntfsmove" is a bit misleading IMHO. > I wouldn't recommend using it yet, since it's not got any error > checking. I took a quick look and the biggest problem I've seen was that resize_nonres_attr() could overflow the MFT record. It's not very probably but it can do happen. > However, if you were to use it, you might see results like: > > http://flatcap.org/ntfs/move_before.png > http://flatcap.org/ntfs/move_after.png Looks nice :) BTW, you don't allow ntldr to be moved. Why? AFAIK the only requirement is it must be in the root directory (because $BOOT has a mini NTFS driver), so it could be moved at the cluster level. Did you _test_ that it doesn't work on NT4 or you _think_ it wouldn't work? Cheers, Szaka |
|
From: Richard R. <nt...@fl...> - 2003-11-12 22:40:05
|
Hi Szaka, > > I've just hacked together "ntfsmove", a precursor to ntfsdefrag. > > I think you could even call it ntfsdefrag already. The name "ntfsmove" > is a bit misleading IMHO. It's just a proof of concept, there's a lot to do yet such as making it safe. If I called it defrag, then people are likely to start using it regardless of safety. I will rename it later. > > I wouldn't recommend using it yet, since it's not got any error > > checking. > > I took a quick look and the biggest problem I've seen was that > resize_nonres_attr() could overflow the MFT record. It's not very > probably but it can do happen. Yes, it's a possibility, but for now not a big worry. I'm moving an entire data run at a time so the attribute is only likely to shrink. > BTW, you don't allow ntldr to be moved. Oh, pure paranoia. I looked at the volume and asked myself: What might I regret moving. Currently that list is: all metadata and ntldr. > Why? AFAIK the only requirement is it must be in the root directory I agree. I think the only two that we *mustn't* touch are $Boot and $MFTMirr. But I don't want to keep rebuilding my windows box. > Did you _test_ that it doesn't work on NT4 or you _think_ it wouldn't work? Think. I still want to test the ntldr thing though - I don't trust Windows :-) Cheers, Rich |
|
From: Szakacsits S. <sz...@si...> - 2003-11-13 18:19:02
|
On Wed, 12 Nov 2003, Richard Russon wrote: > I agree. I think the only two that we *mustn't* touch are $Boot and > $MFTMirr. Only $Boot. $MFTMirr can be moved. My private ntfsresize can move it without problems. I'm just doing some cosmetic work and intensive regression before submitting a huge amount of changes to do the most general data relocations what people usually would like to be supported by ntfsresize. So they will not need to defrag NTFS, turn off VM, etc at all (usually Windows defrag doesn't help anyway) and the volume can be shrunk to even smaller. > But I don't want to keep rebuilding my windows box. No need. VMWare can undo the changes and/or ntfsclone could be also used if you use raw partition. Szaka |
|
From: Will G. <del...@le...> - 2003-11-13 19:19:49
|
> > I agree. I think the only two that we *mustn't* touch are $Boot and > > $MFTMirr. > > Only $Boot. $MFTMirr can be moved. Yes, but doing so also necessitates updating $Boot -- remember, $Boot contains a reference to $MFTMirr. Personally, while I'm sure it work correctly, I'd rather not have a defrag program playing around inside my boot sector. :-) --Will |
|
From: Szakacsits S. <sz...@si...> - 2003-11-13 20:22:27
|
On Thu, 13 Nov 2003, Will Glynn wrote: > > > I agree. I think the only two that we *mustn't* touch are $Boot and > > > $MFTMirr. > > > > Only $Boot. $MFTMirr can be moved. > > Yes, but doing so also necessitates updating $Boot -- remember, $Boot > contains a reference to $MFTMirr. Indeed. I meant moving, not touching them ($Boot is fixed at 0 sector and must be continuous). If I didn't update $Boot, among others, then moving $MFTMirr wouldn't work. > Personally, while I'm sure it work correctly, I'd rather not have a > defrag program playing around inside my boot sector. :-) Yes, for defrag it doesn't make sense. My comments were in general. ntfsresize always needed to update $Boot and preferably move all others (e.g. moving $MFT still not done). Szaka |
|
From: Szakacsits S. <sz...@si...> - 2003-11-14 06:48:41
|
Hi,
[I got this in private, but I answer to the list, others maybe be also
interested and I think there isn't any secretive in the discussion.
I also answered some of the issues privately earlier, so in the future
I could point to the mailing list archive :)]
On Fri, 14 Nov 2003, Richard Russon wrote:
> > I'm just doing ... work ... before submitting ... changes to do the
> > most general data relocations what people usually would like to be
> > supported by ntfsresize.
>
> Please don't. Not as it stands.
But you didn't even see it :)))
> For the last year or so, I've been trying to sort out all the code.
That's appreciated a lot, believe me. But I also think some of them is
a waste of time. See just below:
> Some of it's been trivial stuff, like standardising the command lines.
Ian Jackson wrote earlier at
http://marc.theaimsgroup.com/?l=linux-ntfs-dev&m=104982728729178&w=2
* I'm slightly disturbed by the amount of option-parsing boilerplate
(and thus clone-and-hack) thats appears in the utilities in the
linux-ntfs 1.7.1 source tree. For example, the stuff to implement the
force, help, verbose, quiet, and version options, and the code that's
needed when opterr=0. Are there any plans to rationalise this, or
should I just follow the example of the other tools ?
I agree with him. Counting the command line parsing errors in a standalone
apps is a waste of time (to implement and maintain). Or you think this will
be the interface for the functionality when the utils move to the library?
I don't think so. At least I've never planned for those I wrote.
> It's been boring work, but I'm trying to turn these tools into something
> professional looking.
>
> Not long back I started utils.c, a repository for common bits of code
> and I went round ripping out the duplicates from other apps, thus
> simplifying them.
>
> My tools tend to have a main() with some options parsing and a call to a
> function with lots of parameters. This is the next stage in the
> evolution. Soon each application becomes a shell that deals with the
> command line and a function that does the work.
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. ntfsresize, as a standalone
application, is a very fragile and inefficient interface to partitioning
programs. Working on the options parsing won't make it better.
> And it goes further, the nicely separated function is then moved to a
> separate file, or better still a shared library.
When it's appropriate, to the shared library. To be honest I don't
understand why you put a lot of functions to the separate utils.c file
that must be linked with several apps instead of putting into libntfs.
> 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.
> We currently have separate implementations of cluster find
ntfsresize doesn't _look_ for clusters, it _walks_ all clusters and
relocates what's needed on-the-fly.
> and cluster move.
That's true. But
1) different tools might need different functionality. What I needed
is nobody implemented yet and in the existing ones I didn't find
one to be worth to extend, modify, test, fix, etc. At least not yet.
This doesn't mean they are not ok, only not for me and I don't have
time to try to use them. If you say, they are rock stable and handle
everything I need then I would review, evaluate then use/fix them.
But you wrote "I wouldn't recommend using it yet" and apparently you
test with NT4 what almost nobody uses anymore:
http://www.google.com/press/zeitgeist/sep03_pie.gif
2) In the early stage, I don't see parallel minor implementations a
big drawback. They can "learn" from each other moreover they
can be merged any time, if make sense.
> I haven't written these tools to undermine you, it simply that other
No need for excuse I've never thought that :) It's not a competition, we
are working on the same project. At least the ntldr issue made me think :)
[in file level, I distinguish only $MFT and $MFTMirr].
> people will need their functions and they can't usefully be got at inside
> ntfsresize.
People who asked me I answered. Now I answer here publicly.
> I want to rip out the best bits of each, and get resize to call the
> common code.
From the ntfsresize FAQ:
7. Are there plans for cooperation with Parted?
Yes. Parted is an open source partition manipulation program that also
understands and can modify the filesystems on the partitions. Doing the
support for Parted, before or after implementing full NTFS resize
functionality (resizing fragmented NTFS), depends on users' interest.
So far there were less than 10 such requests compared to the several
_orders_ bigger "please support fragmented volumes".
> In this method, I'm starting ntfsck. It will start with the bitmap
> checking from resize.
Cool. I wrote about this here:
http://marc.theaimsgroup.com/?l=linux-ntfs-dev&m=105949711324625&w=2
- design, write an ntfs_walk_clusters_by_<inode|mft>() function. It's
what at least ntfsresize, ntfsclone, ntfsmeta already have
(walk_inodes()) but it must be a function. One if its parameter
is a struct with many callbacks at different points during the walk.
Please also consider it must be possible to have the callbacks linked at
each stages. E.g. ntfsresize does the consistency check _and_ the shrink
constrains collection at the same inode walking time. Doing them separately
is a big performance hit (twice as slow).
> Thank you for putting up with the possibly patronising words above.
> Now I get to the harsh words. I meant to say these sooner, but I've
> been biting my tongue. I don't think that's benefited either of us.
>
> ntfsresize is an embarrassing mess.
>
> It is a maze of global variables
There are 2 global variables. Please see them here:
http://linux-ntfs.bkbits.net:8080/ntfsprogs-devel/anno/ntfsprogs/ntfsresize.c@1.53?nav=index.html|src/|src/ntfsprogs
ntfs_volume *vol = NULL;
and
struct bitmap lcn_bitmap;
lcn_bitmap could be attached to ntfs_resize_t and the variable that uses
this structure is local and passed between functions. It's one minute to
implement.
'vol' is trickier because it needs _designing_ how the library interface
will be for the resizing. There are several ways to do it but I didn't
think about it long because it's not high priority (see above).
> and exit statements.
That's a very important implementation issue. It makes sure when something
would go unexpected, ntfsresize quites immediately. No even cleanup!
Cleanup is done by the OS, not the app that became unreliable. If I did
cleanup it could mess up things unpredictable. Now it's proven, any time
ntfsresize would unexpectedly quit, the scheduled Windows chkdsk is able to
correct the volume.
Anyway, long story and it needs care. Priority, free time and benefit wise
it was never on the top. I've seen fixing it a high risk.
Nevertheless the new code started to fix some of these because it's
_needed_ with the _new_ code to keep the volume consistent or recoverable
if an unexpected or still unsupported case is hit.
> If you ever get around to integrating resize into another program, that's
> all got to change.
Sure. It's just not the highest priority (i.e. what people request most).
> There are three ways a program call our code: exec, load or compile.
> At the moment everything's relying on exec. It's an awful, clumsy
> method, but it works. ntfs.so is too low a level to be useful, so we
> could use application-level shared lib ntfsapps.so.
Aha! Now I understand why you're doing some of the things that didn't make
any sense before.
However I think ntfsapps.so doesn't sound very good. Maybe one lib between
the two levels, 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).
Of course having more libs will result more problems (see e.g. people
having problems with reiserprogs, progsreiser, etc).
> Our tools are useful, already, but there is so much room for improvement.
There is always, everywhere :) That's why prioritizing shouldn't be
completely neglected. Just do whatever you think is important, my only
request is, please regard the working functionality.
Cheers,
Szaka
|
|
From: Anton A. <ai...@ca...> - 2003-11-14 09:47:35
|
Hi, On Fri, 2003-11-14 at 06:48, Szakacsits Szabolcs wrote: > > ntfsresize is an embarrassing mess. Isn't almost all software? (-; I would say that libntfs and ntfsprogs is actually much less of a mess then a lot of commercial software out there... which is why they don't show anyone their sourcecode in fear of noone wanting to use their software afterwards. (^-; > > There are three ways a program call our code: exec, load or compile. > > At the moment everything's relying on exec. It's an awful, clumsy > > method, but it works. ntfs.so is too low a level to be useful, so we > > could use application-level shared lib ntfsapps.so. > > Aha! Now I understand why you're doing some of the things that didn't make > any sense before. > > However I think ntfsapps.so doesn't sound very good. Maybe one lib between > the two levels, 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). > > Of course having more libs will result more problems (see e.g. people > having problems with reiserprogs, progsreiser, etc). That is true. I am not sure whether we should just have one libntfs which does both lower and higher level functions or two (or more) independent libraries. I think I will just go with whatever people implement. > > Our tools are useful, already, but there is so much room for improvement. > > There is always, everywhere :) That's why prioritizing shouldn't be > completely neglected. Just do whatever you think is important, my only > request is, please regard the working functionality. I agree. It is all a matter of priorities and each of us has a different set of priorities. All of us have very little time to work on ntfs, Rich, Szaka, myself, and everyone else no doubt, all have many commitments in real life so we can never achieve a professional full fledged ntfs library. I think that would be a lost cause... Unless several of us worked full time on it anyway... The best we can do is for each of us to work on things they are interested while trying not to break things for the others (or to at least fix them afterwards). My personal focus is only on low level stuff as I am interested in getting the kernel driver finished and libntfs and ntfsprogs is nothing more than a useful testbed/development environment for me. It's a lot easier to develop ntfs when you don't gave to worry about the kernel crashing, damaging non-ntfs related file systems, etc... (-; And then there are useful things like ltrace, ddd, etc as a bonus. So while I would love to have lots of things cleaned up and organised in ntfsprogs / libntfs I think I will just keep going with ntfstruncate related library functionality until that is finished and I hope that everyone else will keep doing whatever it is they would like to see done. (-: Just adding my thoughts... Cheers, 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/ |
|
From: Richard R. <nt...@fl...> - 2003-11-15 11:01:57
|
Hi Anton, > > > an embarrassing mess. > Isn't almost all software? ... a lot of commercial software > ... why they don't show anyone their sourcecode hehe, very very likely :-) > > However I think ntfsapps.so > I am not sure whether we should just have one libntfs > which does both lower and higher level functions or two (or more) Hmm, tricky. The higher-level ones will always rely on the lower, so it's a question of whether anyone, outside our group, will ever need the low level routines. > My personal focus is only on low level stuff as I am interested in > getting the kernel driver finished and libntfs and ntfsprogs is nothing > more than a useful testbed/development environment for me. For the moment, my focus is the utils. Driver write support is definitely the most requested feature to add, but it will take a long time. However, having a working resize and defrag, allows new people to start using Linux. The two things benefit different groups. > I hope that everyone else will keep doing whatever it is they would like to see > done. (-: Great :-) Cheers, Rich |
|
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 |
|
From: Szakacsits S. <sz...@si...> - 2003-11-16 19:05:30
|
Hi, > > > > 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. Your problem is basically listed in the ntfsresize section of the TODO.ntfsprogs file, what section I wrote 17 months ago: http://linux-ntfs.bkbits.net:8080/ntfsprogs-devel/anno/TODO.ntfsprogs@1.10?nav=index.html|src/ High priority: - support fragmented volumes -- WIP Medium priority: - easy usage by partitioning tools -- WIP - move useful things to libntfs .... WIP means "work in progress". Apparently, for you, the medium priority is the high and the high is not (so) important for you. In short our priorities are different. Nothing wrong with that. If you have other issues, let me know. > > 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. Usually not. After the first parser error the others are probably bogus. One example to demonstrate this is e.g. when you're compiling a C program. Miss a ; and you get a bunch of errors. Fixing just the first one fixes all the "others". Many software parsed grammers are like that. > > 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? I'm suggesting when you find an error during command line options parsing and it makes no sense to continue then return with error. Don't overcomplicate issues. Keep it simple, stupid. The best code is the no code. If no code then no time wasted to implement, test, debug, maintain, it also gives the possible best performance, no need to document, etc. > > 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. You misunderstand me. Again because our priorities are different. First of all I talk about ntfs tools I wrote (highest priority is reliability and usefulness of the most demanded utils). Secondly the new code made the bits reusable that were needed ... by ntfsresize. If they are still not reusable for you, well, I can again only say it's not important for me, now. Moreover, given several constrains, it doesn't make sense to make reusable something what I even don't know it will work in the end. It's just a baggage for what I don't have the time to carry. > I should have complained earlier, but you've been writing a useful tool, Yes, you should have, as Anton did 17 months ago for other things. I did what he asked or I explained why I don't. But even if you have asked 17 months ago, I'm not sure that would have changed the priorities. However at that time it had much greater chances than now, yes. Today it's not so important because there is an "interface" in use by several tools. The important now is not to break that interface and for the future is to provide additionally a real, efficient interface by using a shared library (being libntfs or whatever). You want the later one now but as I told, for me, it still doesn't make sense. Read, right now I don't have time to care about it. If one has the time, I'm very happy about it - if it's done properly. > But... To reuse any code from resize is a major undertaking. I don't think so. But it's not high priority for me to take care about, again. > 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. When I wrote chkdsk pass 1 in ntfsresize, I didn't know it was that. It just made a lot of sense to resize a volume only if you can exactly account for every each clusters. I got to know only later on, this is what Windows chkdsk does basically in pass one. And I wrote in my earlier email, why it's "intertwined" with other things (performance, less user annoyance). > > 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. Definitely not. You overreact the issue. > > 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? If one wanted resize in a library then she/he could do it in hours. > 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. It's far not that simple. You must ask a lof of additional questions and make a decision what fits your priorities best. Our priorities are different, so don't wonder I don't do what you want. > > 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 99% is not 100%. If something in that 1% hits then 95% of the Windows users data are effected/damaged. > 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? I didn't say it's wrong you test against NT4. But it's a factor that must be considered. > > 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? Resize and defrag is not the same. What they have in common is they move data. But for _different_ purposes. There is a picture in people (probably based on the old norton defrag or whatever) that defrag means, all data is moved to the beginning of the volume, they're allocated on a continuous place, etc. Well, no or not anymore (in real, never meant). Resize needs to _relocate_ data from the supposed to be unfreed space. Actually if it can't allocate a continuous space for the data to be relocated, it will even _fragment_ a file. Its job is resizing, not defragmenting. People who want to resize, don't want to wait long for a defragmentation. In fact they don't want to wait at all. Today many of them defragments, just to figure out the next day that it didn't work so well as they expected. Or it made things even worse. No, I was never interested in NTFS defragmentation and of course I've never thought ntfsresize must defragment the volume. If I phrased like that I just did because people asked that way and it's also easier to explain. None of the users are really interested in the low level details and indeed, none of them should. However it turned out, some commercial defragmenters do a poor job. So it would be really interesting just to demonstrate, that it can be done better. That's also not a high priority for me, I'd be very glad to see if you (or anybody else) would do it. So yes, a separate ntfsdefrag utility would be nice. > Speaking of which, where's the source to "ntfsmeta"? I've seen you give > out the binary plenty of times. Yes, I pointed people to it when need arose to investigate user issues. I also asked you several times if you want the source but your only answer was so far: anybody could write it before breakfast. I have only the binary at hand but I must have the source on one of the backups (moves, new computers, etc). I'll hunt for it and put somewhere or send if you want. Anyway, some of the fields are printed incorrectly and I wanted to fix it for a while. > > It makes sure when something would go unexpected, ntfsresize quits > > immediately. No even cleanup! > > Hmm... You cut out the explanation and now reading the above makes a different impression. So again: ntfsresize changes metadata under itself. If, in cases, it tried to cleanup then the cleanup parts in the library could revert part of a consistent change that would make the volume overall inconsistent or unrecoverable. So no cleanup above means, the volume stays always consistent or recoverable while trying to cleanup could end up in a disaster considering users' data (well, not really but I bored people already long enough, it's time to vanish). Szaka |
