|
From: Szakacsits S. <sz...@si...> - 2004-02-26 18:05:42
|
On Thu, 26 Feb 2004, Anton Altaparmakov wrote: > On Thu, 2004-02-26 at 16:05, Szakacsits Szabolcs wrote: > > - "everybody" uses or will use XP/W2K/Longhorn (version 3.1), why > > the pain for the conversion, e.g. when in [qt]parted, diskdrake, > > etc one wants to create an NTFS. > > I disagree about the "everybody" but I guess long term that is going to > happen. See yourself at google. For the overall 66% NT(FS) based OS'es 95% uses NTFS 3.x and only 5% uses NTFS 1.2. http://www.google.com/press/zeitgeist.html > But why would anyone ever want to create an ntfs partition while > installing Linux? This codebase is used in many free partitioning tools. Those are the only ones who can manage NTFS. So it's quite probable it's not only used when one installs Linux but whenever they want to reorganize the disk for whatever reason. > mkntfs could just internally call tunentfs to switch the format. After > all it only involves changing three bytes on the partition so is a > trivial operation. There are a bit more differences between NTFS 1.2 and 3.x ... > Neither am I in creating mkntfs that makes NTFS 3.1 partitions as I > don't see any point for having it. (-; I think that's the main reason why nobody found that fatal bug in ntfs_get_size_for_mapping_pairs and ntfs_mapping_pairs_build until I systematically started to test the NTFS 3.x code and what would trash users data if sparse _or_ compressed file runlists were modified. I didn't remark at that time but in the changelog comments you downgraded the issue to "sparse and compressed files with holes". No, it was much more serious. Sparse files are not so common but compressed file _are_. Do you remember when I mentioned to Flatcap why he tests ntfsmove on NT4 instead of W2K/XP? Sparse/compressed files. I was right. It had a very serious bug. If one used ntfsmove on XP/W2K/W2K3 then it could trash his data. Actually it can trash data other ways what I also told at that time (MFT record overflow). Ok in short, it only makes sense testing and developing for the NTFS version what most people use and not for something that basically nobody (I think, not many of those 5%, still using NT4, wants to migrate to Linux). > Just add an option to mkntfs to allow creation of ntfs 3.0 and 3.1 and That's what I meant. > You might even be able to get away with leaving the version to 1.2 and > only setting the VOLUME_UPGRADE_ON_MOUNT flag. libntfs and kernel driver won't upgrade it. > That may be sufficient Some on-disk structures are a bit extended and some files are moved around, deleted or added. > Amount of coding effort needed is < half an hour. I would prefer a real-world NTFS 3.x instead of a hacked up one that isn't 1.2 anymore nor really 3.x yet. > About ntfsdebug, yes I agree it would be very useful but no I don't have > the time to write it. I didn't mean you write it. This would be also a good entry level job for somebody who would like to help out. It would be highly useful for anybody. > Although I would much rather have a ntfsdiskedit rather than an > ntfsdebug but perhaps you meant the same thing... Perhaps :) I meant a console tool and using that one anybody could view and modify NTFS. Scriptable would be wonderful :-) > Feel free to submit patches for making functions smaller if it would > make the code clearer to others... (-; I'm very happy to hear this :-) It would also eliminate a lot of copy-pastes and unneded multi-line codes. Szaka |
