|
From: Anton A. <ai...@ca...> - 2006-11-29 08:49:24
|
Hi Yura,
On Tue, 2006-11-28 at 16:52 +0200, Yura Pakhuchiy wrote:
> =D0=A3 Tue, 28/11/2006 =D1=83 11:37 +0000, Anton Altaparmakov =D0=BF=D1=
=96=D1=88=D0=B0:
> > Are we in a state to make a release ASAP? I want to get the fixed
> > ntfsresize out there quickly...
>=20
> Argh, I definitely do not want release current ntfsmount ATM. It
> requires so more work.
Ok.
> > Yura I am asking you in particular because you can say what state
> > ntfsmount is in... It is releasable at the moment or are you in the
> > middle of working on things?
>=20
> Here is main problems:
> * option parsing (see below)
> * broken "touch a b; mv a b"
> * writing big files is totally slow, except case when volume 0-1%
> fragmented
> * code is still endianness unsafe (I applied everything from
> ntfs-3g about this, but Bob Zhang fixed not all problems, eg.
> splitting index root to index allocation do not work)
> * valgrind reports several memleaks
> * some other minor things
>=20
> > There is the blockdev fuse option that you
> > want to only happen for root for example you said you wanted to work on
> > so I assume you want to finish at least that off before we release.
> >=20
> > btw. On that blockdev option. You could simply change:
> >=20
> > vol =3D utils_mount_volume(device, ((ctx->ro) ? NTFS_MNT_RDONLY : 0) |
> > ((ctx->noatime) ? NTFS_MNT_NOATIME : 0) |
> > - NTFS_MNT_NOT_EXCLUSIVE /*| NTFS_MNT_CASE_SENSITIVE*/,
> > ctx->force);
> >=20
> > To:
> >=20
> > vol =3D utils_mount_volume(device, ((ctx->ro) ? NTFS_MNT_RDONLY : 0) |
> > ((ctx->noatime) ? NTFS_MNT_NOATIME : 0) |
> > + (!geteuid() ? NTFS_MNT_NOT_EXCLUSIVE : 0) |
> > + 0/* NTFS_MNT_CASE_SENSITIVE*/,
> > ctx->force);
> >=20
> > That would only set the option when ntfsmount is invoked as root or whe=
n
> > the ntfsmount executable is setuid root, what do you think?
>=20
> ;-) Yes, I know. But I want rewrite whole option parsing because:
> * It is one big ugly hack (it was written when FUSE had not
> anything for option parsing, thus every FUSE user had to write
> its own.)
> * Several options are not updated in CVS and adding support for
> this require more ugly hacks (or proper rewrite option parsing)
> * With upgrade to new FUSE API incorrect mount options are not
> reported (also requires use of new option parsing or hacks for
> current implementation)
>=20
> So, I see 2 variants:
> 1. Give me 2 weeks. I will fix everything and we will release great
> new ntfsprogs with full read/write.
> 2. Apply your last patches to 1.13.1 and release 1.13.2, leave
> everything else for next major release.
2 weeks is no problem at all. That was about what I had envisaged
anyway...
In two weeks we can review whether to branch 1.13.1 of for a point
release or not.
> BTW, about versions. I propose to change scheme to following to avoid
> such problems in the future.
Where is the problem?
> In CVS we have always x.y.0 version. That
> will be next major release. In case if we found some important bug, we
> make x.y-1.z release, by releasing diff in the patches directory (like
> vim maintainer does). We need to separate minor version from autotools
> and keep it only in some header file for this. If one of developers
> believes that we need new z version, then he sends email to -dev list
> with patch. And if there is no objections in 48 hours, then he can put
> it to patches dir somewhere on our server and after this patch becomes
> official and distros can update their packages. I think this will
> improve stability and make less work for everyone. What do you think?
I do not understand what you mean. What is wrong with current working
practice? We have branches in CVS and if we need to make a bug fix
release, we can checkout the 1.13.1 branch apply the fix, commit it as
1.13.2 branch and then make a 1.13.2 release. But that is not needed.
We have not had a release of ntfsprogs in 6 months or so so it is about
time we made a new one so I am more keen on making a full blown release
rather than just a bug fix one.
Best regards,
Anton
--=20
Anton Altaparmakov <aia21 at cam.ac.uk> (replace at with @)
Unix Support, Computing Service, University of Cambridge, CB2 3QH, UK
Linux NTFS maintainer, http://www.linux-ntfs.org/
|
