[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: What would I do without partimage?

On Sat, 17 Dec 2005 21:11:04 +0200 (MET DST)
Szakacsits Szabolcs <szaka@sienet.hu> wrote:

> nospam-51121@carolina.rr.com (William Ballard) writes:
> > You can't mount a [ntfsclone] image that has been saved with
> > --save-image.
> If you want a compressed and mountable image then use ntfsclone without the 
> --save-image option and with a compressed filesystem.
> > I tried ntfsclone and it works about as fast as partimage, and it's
> > definitely less cumbersome that partimage; however the resulting gzipped
> > image file from a 20GB partition with 2GB of actual data was about 60MB
> > larger: 840mb versus 780mb.  The partimage image was also gzipped.
> Two possible explanations:
> 1) Both patimage and ntfsclone save the used blocks based on the block 
> allocation bitmap, however partimage doesn't have consistency check while 
> ntfsclone has. This means if your ntfs is inconsistent (which is 
> unfortunately more common than most people would like it) then partimage 
> will save less data than needed and obviously you will lose those.
> 2) partimage used a higher compression option than the one was used with 
> ntfsclone, which could be basically anything given that one can have the 
> image in a pipe stream.
> > I'm also going to file a bug against ntfsprogs that ntfsclone should be
> > packaged separately from the rest of ntfsprogs.  ntfsclone is actually
> > useful; the rest of those programs are either unnecessary or flat
> > dangerous.  
> They are much less dangerous than cp, tar, partimage, parted, etc. Over the 
> last three years there wasn't even one report about damaged ntfs (using our 
> code) even if they are pretty widely used (directly or indirectly over a 
> million users).
> Actually due to their reliability, several serious problems were discovered 
> at least in the previously mentioned utilities: tar trashes any 4+ GB 
> sparse files for over a year when the --sparse option is used, parted 
> sometimes still corrupts partition tables with head number 240, etc.
> > The fact that ntfsclone is packaged with a tool called "fixntfs" 
> Ntfsfix currently is distributed to fix corrupted NTFS which were corrupted 
> by the Windows NTFS driver, not by the new Linux NTFS code.
> Originally ntfsfix was developed by the new Linux NTFS developers to "fix" 
> corrupted NTFS which were corrupted by the NT4 NTFS kernel driver 5 years 
> ago and which driver was developed then abandoned by their developers. That 
> driver is not used for years now and write was disabled 3-4 years ago.
> > or somethign who's man page says "always run this after running any of 
> > the other utilities in this package before booting or your NTFS partition 
> > will be completely destroyed"
> This was NEVER in the ntfsfix manual page, your claim is absolutely untrue.
> I wrote ntfsresize, ntfsclone, worked on ntfsfix and I've never released 
> non-stable code. Here is the ntfsfix manual which has nothing even close to 
> what you're saying:
>   http://wiki.linux-ntfs.org/doku.php?id=man:ntfsfix
> As a matter of fact, I was who rewrote the "5 years old" ntfsfix manual 
> this year
>   http://cvs.sf.net/viewcvs.py/linux-ntfs/ntfsprogs/ntfsprogs/ntfsfix.8.in?r1=1.5&r2=1.6
> because it still referred to the old, dead NTFS kernel driver which was 
> never developed, maintained and supported by the new NTFS developers and 
> which had write disabled in the last 3-4 years. 
> All the utils in ntfsprogs and the current kernel code was written from 
> scratch to also support W2K, XP, W2K3, Vista and nothing is shared with the 
> old, broken and experimantal NT4 NTFS driver.
> > makes me feel squeamish about ntfsclone, although as I said it's a 
> > different animal and people report it as stable.
> Yes and that's not by accident but due to a lot of very careful work. It 
> was supposed to be always stable since I publicly released it, almost three 
> years ago. Ntfsclone is intensively used and also crucial during 
> development and regression testing.
> 	Szaka
> -- 
> To UNSUBSCRIBE, email to debian-user-REQUEST@lists.debian.org 
> with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org

I've been eager for an answer to a question and i always forget to google about it :)

Is NTFS support safe to use for writing? Are all functions implemented?

If no time to answer could you just please direct me where to look for this information. I know this is constant development, but i would be very interested in trying it out.


Reply to: