linux-ntfs-dev — Development discussions and bug reports.

Re: [Linux-NTFS-Dev] Re: [Linux-NTFS-cvs] CVS: ntfsprogs/libntfs attrib.c,1.178,1.179

[Yura P. <y.p...@sa...>]

=D0=92 =D0=9F=D1=82=D0=BD, 30/09/2005 =D0=B2 14:06 +0100, Anton Altaparmako=
v =D0=BF=D0=B8=D1=88=D0=B5=D1=82:
> On Fri, 2005-09-30 at 15:56 +0300, Yura Pakhuchiy wrote:
> > =D0=92 =D0=9F=D1=82=D0=BD, 30/09/2005 =D0=B2 13:30 +0100, Anton Altapar=
makov =D0=BF=D0=B8=D1=88=D0=B5=D1=82:
> > > On Fri, 2005-09-30 at 14:46 +0300, Yura Pakhuchiy wrote:
> > > > =D0=92 =D0=9F=D1=82=D0=BD, 30/09/2005 =D0=B2 11:02 +0100, Anton Alt=
aparmakov =D0=BF=D0=B8=D1=88=D0=B5=D1=82:
> > > > > > --- attrib.c	28 Sep 2005 13:47:47 -0000	1.178
> > > > > > +++ attrib.c	30 Sep 2005 09:52:05 -0000	1.179
> > > > > > @@ -2554,7 +2554,7 @@ int ntfs_resident_attr_record_add(ntfs_i
> > > > > >  	}
> > > > > > =20
> > > > > >  	/* Locate place where record should be. */
> > > > > > -	ctx =3D ntfs_attr_get_search_ctx(ni, NULL);
> > > > > > +	ctx =3D ntfs_attr_get_search_ctx(NULL, ni->mrec);
> > > > > >  	if (!ctx)
> > > > > >  		return -1;
> > > > > >  	if (!ntfs_attr_lookup(type, name, name_len,
> > > > > > @@ -2679,7 +2679,7 @@ int ntfs_non_resident_attr_record_add(nt
> > > > > >  	}
> > > > > > =20
> > > > > >  	/* Locate place where record should be. */
> > > > > > -	ctx =3D ntfs_attr_get_search_ctx(ni, NULL);
> > > > > > +	ctx =3D ntfs_attr_get_search_ctx(NULL, ni->mrec);
> > > > > >  	if (!ctx)
> > > > > >  		return -1;
> > > > > >  	if (!ntfs_attr_lookup(type, name, name_len, CASE_SENSITIVE,
> > > > > > @@ -3342,7 +3342,7 @@ int ntfs_attr_record_move_to(ntfs_attr_s
> > > > > > =20
> > > > > >  	/* Find place in MFT record where attribute will be moved. */
> > > > > >  	a =3D ctx->attr;
> > > > > > -	nctx =3D ntfs_attr_get_search_ctx(ni, NULL);
> > > > > > +	nctx =3D ntfs_attr_get_search_ctx(NULL, ni->mrec);
> > > > > >  	if (!nctx) {
> > > > > >  		err =3D errno;
> > > > > >  		Dprintf("%s(): Couldn't obtain search context.\n",
> > > > >=20
> > > > > The above three will now always fail when name !=3D NULL in the c=
all to
> > > > > ntfs_attr_lookup().  You must use ntfs_attr_find() instead.
> > > >=20
> > > > Why you add such check? What problems can happen in case sensitive
> > > > lookup?
> > >=20
> > > You _cannot_ perform case insensitive lookup without an upcase table =
by
> > > definition of what case insensitive means.  attr_find/lookup _have_ t=
o
> > > do case insensitive comparison of the name.  They cannot do this if n=
o
> > > upcase table is present.
> > >=20
> > > As I said in earlier message the correct fix would be to add either t=
he
> > > volume or the upcase table + length to somewhere, either the search
> > > context itself so there would be "ntfs_inode_get_search_ctx(ntfs_inod=
e
> > > *ni)" and "ntfs_mft_get_search_ctx(ntfs_volume *vol, MFT_RECORD *mrec=
)".
> > > Or alternatively modify ntfs_attr_find() to also take the upcase tabl=
e
> > > (or the volume I suppose but that will cause problems with places tha=
t
> > > do not have a volume) and then you can pass it in when you have acqui=
red
> > > the context with (NULL, mrec)...
> > >=20
> > > Basically ntfs_attr_find() MUST AT ALL TIMES have access to upcase ta=
ble
> > > if a name is provided for the comparisons.  At present if you get a
> > > search context with (NULL, mrec) you do NOT have an upcase table in
> > > _lookup/find so they cannot execute correctly.
> > >=20
> > > Just read ntfs_attr_find():
> > >=20
> > > if (name =3D=3D AT_UNNAMED) {
> > >         /* The search failed if the found attribute is named. */
> > >         if (a->name_length) {
> > >                 errno =3D ENOENT;
> > >                 return -1;
> > >         }
> > > } else if (name && !ntfs_names_are_equal(name, name_len,
> > >             (ntfschar*)((char*)a + le16_to_cpu(a->name_offset)),
> > >             a->name_length, ic, upcase, upcase_len)) {
> > >         register int rc;
> > >=20
> > >         rc =3D ntfs_names_collate(name, name_len,
> > >                         (ntfschar*)((char*)a +
> > >                         le16_to_cpu(a->name_offset)),
> > >                         a->name_length, 1, IGNORE_CASE,
> > >                         upcase, upcase_len);
> > >=20
> > >=20
> > > ************************************
> > > THIS REQUIRES UPCASE TABLE
> > > ************************************
> > >=20
> > >=20
> > >         /*
> > >          * If @name collates before a->name, there is no
> > >          * matching attribute.
> > >          */
> > >         if (rc =3D=3D -1) {
> > >                 errno =3D ENOENT;
> > >                 return -1;
> > >         }
> > >         /* If the strings are not equal, continue search. */
> > >         if (rc)
> > >                 continue;
> > >         rc =3D ntfs_names_collate(name, name_len,
> > >                         (ntfschar*)((char*)a +
> > >                         le16_to_cpu(a->name_offset)),
> > >                         a->name_length, 1, CASE_SENSITIVE,
> > >                         upcase, upcase_len);
> > >         if (rc =3D=3D -1) {
> > >                 errno =3D ENOENT;
> > >                 return -1;
> > >         }
> > >         if (rc)
> > >                 continue;
> > > }
> > >=20
> > > Sorry but which part of this do you not understand?  What you were do=
ing
> > > worked only by chance/accident/coincidence.  It WOULD cause data
> > > corruption and I am not having it.
> >=20
> > Now I understand problem, didn't thought earlier that ntfs_attr_find ma=
y
> > need upcase table even for case sensitive lookups.=20
>=20
> Ah!  Yes, it does.  FWIW I had forgotten/not noticed that, too, until I
> came to look into the problem and when I discovered it, I wrote and
> committed the mega patch (last week it was I think?).  In the kernel you
> _always_ have the inode so the problem never arises...
>=20
> > Thank you for
> > explanation. I commit version you proposed to use.
>=20
> You are welcome!  (-:
>=20
> Sorry about the "somewhat" heated earlier email...

No problem. I think that my emails was also not perfectly correct, since
earlier I did not understand that megapatch and very disliked it because
of that.

--=20
Best regards,
        Yura

Re: [Linux-NTFS-Dev] Re: [Linux-NTFS-cvs] CVS: ntfsprogs/libntfs attrib.c,1.178,1.179

[Anton A. <ai...@ca...>]

On Fri, 2005-09-30 at 15:56 +0300, Yura Pakhuchiy wrote:
> =D0=92 =D0=9F=D1=82=D0=BD, 30/09/2005 =D0=B2 13:30 +0100, Anton Altaparma=
kov =D0=BF=D0=B8=D1=88=D0=B5=D1=82:
> > On Fri, 2005-09-30 at 14:46 +0300, Yura Pakhuchiy wrote:
> > > =D0=92 =D0=9F=D1=82=D0=BD, 30/09/2005 =D0=B2 11:02 +0100, Anton Altap=
armakov =D0=BF=D0=B8=D1=88=D0=B5=D1=82:
> > > > > --- attrib.c	28 Sep 2005 13:47:47 -0000	1.178
> > > > > +++ attrib.c	30 Sep 2005 09:52:05 -0000	1.179
> > > > > @@ -2554,7 +2554,7 @@ int ntfs_resident_attr_record_add(ntfs_i
> > > > >  	}
> > > > > =20
> > > > >  	/* Locate place where record should be. */
> > > > > -	ctx =3D ntfs_attr_get_search_ctx(ni, NULL);
> > > > > +	ctx =3D ntfs_attr_get_search_ctx(NULL, ni->mrec);
> > > > >  	if (!ctx)
> > > > >  		return -1;
> > > > >  	if (!ntfs_attr_lookup(type, name, name_len,
> > > > > @@ -2679,7 +2679,7 @@ int ntfs_non_resident_attr_record_add(nt
> > > > >  	}
> > > > > =20
> > > > >  	/* Locate place where record should be. */
> > > > > -	ctx =3D ntfs_attr_get_search_ctx(ni, NULL);
> > > > > +	ctx =3D ntfs_attr_get_search_ctx(NULL, ni->mrec);
> > > > >  	if (!ctx)
> > > > >  		return -1;
> > > > >  	if (!ntfs_attr_lookup(type, name, name_len, CASE_SENSITIVE,
> > > > > @@ -3342,7 +3342,7 @@ int ntfs_attr_record_move_to(ntfs_attr_s
> > > > > =20
> > > > >  	/* Find place in MFT record where attribute will be moved. */
> > > > >  	a =3D ctx->attr;
> > > > > -	nctx =3D ntfs_attr_get_search_ctx(ni, NULL);
> > > > > +	nctx =3D ntfs_attr_get_search_ctx(NULL, ni->mrec);
> > > > >  	if (!nctx) {
> > > > >  		err =3D errno;
> > > > >  		Dprintf("%s(): Couldn't obtain search context.\n",
> > > >=20
> > > > The above three will now always fail when name !=3D NULL in the cal=
l to
> > > > ntfs_attr_lookup().  You must use ntfs_attr_find() instead.
> > >=20
> > > Why you add such check? What problems can happen in case sensitive
> > > lookup?
> >=20
> > You _cannot_ perform case insensitive lookup without an upcase table by
> > definition of what case insensitive means.  attr_find/lookup _have_ to
> > do case insensitive comparison of the name.  They cannot do this if no
> > upcase table is present.
> >=20
> > As I said in earlier message the correct fix would be to add either the
> > volume or the upcase table + length to somewhere, either the search
> > context itself so there would be "ntfs_inode_get_search_ctx(ntfs_inode
> > *ni)" and "ntfs_mft_get_search_ctx(ntfs_volume *vol, MFT_RECORD *mrec)"=
.
> > Or alternatively modify ntfs_attr_find() to also take the upcase table
> > (or the volume I suppose but that will cause problems with places that
> > do not have a volume) and then you can pass it in when you have acquire=
d
> > the context with (NULL, mrec)...
> >=20
> > Basically ntfs_attr_find() MUST AT ALL TIMES have access to upcase tabl=
e
> > if a name is provided for the comparisons.  At present if you get a
> > search context with (NULL, mrec) you do NOT have an upcase table in
> > _lookup/find so they cannot execute correctly.
> >=20
> > Just read ntfs_attr_find():
> >=20
> > if (name =3D=3D AT_UNNAMED) {
> >         /* The search failed if the found attribute is named. */
> >         if (a->name_length) {
> >                 errno =3D ENOENT;
> >                 return -1;
> >         }
> > } else if (name && !ntfs_names_are_equal(name, name_len,
> >             (ntfschar*)((char*)a + le16_to_cpu(a->name_offset)),
> >             a->name_length, ic, upcase, upcase_len)) {
> >         register int rc;
> >=20
> >         rc =3D ntfs_names_collate(name, name_len,
> >                         (ntfschar*)((char*)a +
> >                         le16_to_cpu(a->name_offset)),
> >                         a->name_length, 1, IGNORE_CASE,
> >                         upcase, upcase_len);
> >=20
> >=20
> > ************************************
> > THIS REQUIRES UPCASE TABLE
> > ************************************
> >=20
> >=20
> >         /*
> >          * If @name collates before a->name, there is no
> >          * matching attribute.
> >          */
> >         if (rc =3D=3D -1) {
> >                 errno =3D ENOENT;
> >                 return -1;
> >         }
> >         /* If the strings are not equal, continue search. */
> >         if (rc)
> >                 continue;
> >         rc =3D ntfs_names_collate(name, name_len,
> >                         (ntfschar*)((char*)a +
> >                         le16_to_cpu(a->name_offset)),
> >                         a->name_length, 1, CASE_SENSITIVE,
> >                         upcase, upcase_len);
> >         if (rc =3D=3D -1) {
> >                 errno =3D ENOENT;
> >                 return -1;
> >         }
> >         if (rc)
> >                 continue;
> > }
> >=20
> > Sorry but which part of this do you not understand?  What you were doin=
g
> > worked only by chance/accident/coincidence.  It WOULD cause data
> > corruption and I am not having it.
>=20
> Now I understand problem, didn't thought earlier that ntfs_attr_find may
> need upcase table even for case sensitive lookups.=20

Ah!  Yes, it does.  FWIW I had forgotten/not noticed that, too, until I
came to look into the problem and when I discovered it, I wrote and
committed the mega patch (last week it was I think?).  In the kernel you
_always_ have the inode so the problem never arises...

> Thank you for
> explanation. I commit version you proposed to use.

You are welcome!  (-:

Sorry about the "somewhat" heated earlier email...

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 / IRC: #ntfs on irc.freenode.net
WWW: http://linux-ntfs.sf.net/ & http://www-stu.christs.cam.ac.uk/~aia21/

Re: [Linux-NTFS-Dev] Re: [Linux-NTFS-cvs] CVS: ntfsprogs/libntfs attrib.c,1.178,1.179

[Yura P. <y.p...@sa...>]

=D0=92 =D0=9F=D1=82=D0=BD, 30/09/2005 =D0=B2 13:30 +0100, Anton Altaparmako=
v =D0=BF=D0=B8=D1=88=D0=B5=D1=82:
> On Fri, 2005-09-30 at 14:46 +0300, Yura Pakhuchiy wrote:
> > =D0=92 =D0=9F=D1=82=D0=BD, 30/09/2005 =D0=B2 11:02 +0100, Anton Altapar=
makov =D0=BF=D0=B8=D1=88=D0=B5=D1=82:
> > > > --- attrib.c	28 Sep 2005 13:47:47 -0000	1.178
> > > > +++ attrib.c	30 Sep 2005 09:52:05 -0000	1.179
> > > > @@ -2554,7 +2554,7 @@ int ntfs_resident_attr_record_add(ntfs_i
> > > >  	}
> > > > =20
> > > >  	/* Locate place where record should be. */
> > > > -	ctx =3D ntfs_attr_get_search_ctx(ni, NULL);
> > > > +	ctx =3D ntfs_attr_get_search_ctx(NULL, ni->mrec);
> > > >  	if (!ctx)
> > > >  		return -1;
> > > >  	if (!ntfs_attr_lookup(type, name, name_len,
> > > > @@ -2679,7 +2679,7 @@ int ntfs_non_resident_attr_record_add(nt
> > > >  	}
> > > > =20
> > > >  	/* Locate place where record should be. */
> > > > -	ctx =3D ntfs_attr_get_search_ctx(ni, NULL);
> > > > +	ctx =3D ntfs_attr_get_search_ctx(NULL, ni->mrec);
> > > >  	if (!ctx)
> > > >  		return -1;
> > > >  	if (!ntfs_attr_lookup(type, name, name_len, CASE_SENSITIVE,
> > > > @@ -3342,7 +3342,7 @@ int ntfs_attr_record_move_to(ntfs_attr_s
> > > > =20
> > > >  	/* Find place in MFT record where attribute will be moved. */
> > > >  	a =3D ctx->attr;
> > > > -	nctx =3D ntfs_attr_get_search_ctx(ni, NULL);
> > > > +	nctx =3D ntfs_attr_get_search_ctx(NULL, ni->mrec);
> > > >  	if (!nctx) {
> > > >  		err =3D errno;
> > > >  		Dprintf("%s(): Couldn't obtain search context.\n",
> > >=20
> > > The above three will now always fail when name !=3D NULL in the call =
to
> > > ntfs_attr_lookup().  You must use ntfs_attr_find() instead.
> >=20
> > Why you add such check? What problems can happen in case sensitive
> > lookup?
>=20
> You _cannot_ perform case insensitive lookup without an upcase table by
> definition of what case insensitive means.  attr_find/lookup _have_ to
> do case insensitive comparison of the name.  They cannot do this if no
> upcase table is present.
>=20
> As I said in earlier message the correct fix would be to add either the
> volume or the upcase table + length to somewhere, either the search
> context itself so there would be "ntfs_inode_get_search_ctx(ntfs_inode
> *ni)" and "ntfs_mft_get_search_ctx(ntfs_volume *vol, MFT_RECORD *mrec)".
> Or alternatively modify ntfs_attr_find() to also take the upcase table
> (or the volume I suppose but that will cause problems with places that
> do not have a volume) and then you can pass it in when you have acquired
> the context with (NULL, mrec)...
>=20
> Basically ntfs_attr_find() MUST AT ALL TIMES have access to upcase table
> if a name is provided for the comparisons.  At present if you get a
> search context with (NULL, mrec) you do NOT have an upcase table in
> _lookup/find so they cannot execute correctly.
>=20
> Just read ntfs_attr_find():
>=20
> if (name =3D=3D AT_UNNAMED) {
>         /* The search failed if the found attribute is named. */
>         if (a->name_length) {
>                 errno =3D ENOENT;
>                 return -1;
>         }
> } else if (name && !ntfs_names_are_equal(name, name_len,
>             (ntfschar*)((char*)a + le16_to_cpu(a->name_offset)),
>             a->name_length, ic, upcase, upcase_len)) {
>         register int rc;
>=20
>         rc =3D ntfs_names_collate(name, name_len,
>                         (ntfschar*)((char*)a +
>                         le16_to_cpu(a->name_offset)),
>                         a->name_length, 1, IGNORE_CASE,
>                         upcase, upcase_len);
>=20
>=20
> ************************************
> THIS REQUIRES UPCASE TABLE
> ************************************
>=20
>=20
>         /*
>          * If @name collates before a->name, there is no
>          * matching attribute.
>          */
>         if (rc =3D=3D -1) {
>                 errno =3D ENOENT;
>                 return -1;
>         }
>         /* If the strings are not equal, continue search. */
>         if (rc)
>                 continue;
>         rc =3D ntfs_names_collate(name, name_len,
>                         (ntfschar*)((char*)a +
>                         le16_to_cpu(a->name_offset)),
>                         a->name_length, 1, CASE_SENSITIVE,
>                         upcase, upcase_len);
>         if (rc =3D=3D -1) {
>                 errno =3D ENOENT;
>                 return -1;
>         }
>         if (rc)
>                 continue;
> }
>=20
> Sorry but which part of this do you not understand?  What you were doing
> worked only by chance/accident/coincidence.  It WOULD cause data
> corruption and I am not having it.

Now I understand problem, didn't thought earlier that ntfs_attr_find may
need upcase table even for case sensitive lookups. Thank you for
explanation. I commit version you proposed to use.

--=20
Cheers,
        Yura

[Linux-NTFS-Dev] Re: [Linux-NTFS-cvs] CVS: ntfsprogs/libntfs attrib.c,1.178,1.179

[Anton A. <ai...@ca...>]

On Fri, 2005-09-30 at 14:46 +0300, Yura Pakhuchiy wrote:
> =D0=92 =D0=9F=D1=82=D0=BD, 30/09/2005 =D0=B2 11:02 +0100, Anton Altaparma=
kov =D0=BF=D0=B8=D1=88=D0=B5=D1=82:
> > > --- attrib.c	28 Sep 2005 13:47:47 -0000	1.178
> > > +++ attrib.c	30 Sep 2005 09:52:05 -0000	1.179
> > > @@ -2554,7 +2554,7 @@ int ntfs_resident_attr_record_add(ntfs_i
> > >  	}
> > > =20
> > >  	/* Locate place where record should be. */
> > > -	ctx =3D ntfs_attr_get_search_ctx(ni, NULL);
> > > +	ctx =3D ntfs_attr_get_search_ctx(NULL, ni->mrec);
> > >  	if (!ctx)
> > >  		return -1;
> > >  	if (!ntfs_attr_lookup(type, name, name_len,
> > > @@ -2679,7 +2679,7 @@ int ntfs_non_resident_attr_record_add(nt
> > >  	}
> > > =20
> > >  	/* Locate place where record should be. */
> > > -	ctx =3D ntfs_attr_get_search_ctx(ni, NULL);
> > > +	ctx =3D ntfs_attr_get_search_ctx(NULL, ni->mrec);
> > >  	if (!ctx)
> > >  		return -1;
> > >  	if (!ntfs_attr_lookup(type, name, name_len, CASE_SENSITIVE,
> > > @@ -3342,7 +3342,7 @@ int ntfs_attr_record_move_to(ntfs_attr_s
> > > =20
> > >  	/* Find place in MFT record where attribute will be moved. */
> > >  	a =3D ctx->attr;
> > > -	nctx =3D ntfs_attr_get_search_ctx(ni, NULL);
> > > +	nctx =3D ntfs_attr_get_search_ctx(NULL, ni->mrec);
> > >  	if (!nctx) {
> > >  		err =3D errno;
> > >  		Dprintf("%s(): Couldn't obtain search context.\n",
> >=20
> > The above three will now always fail when name !=3D NULL in the call to
> > ntfs_attr_lookup().  You must use ntfs_attr_find() instead.
>=20
> Why you add such check? What problems can happen in case sensitive
> lookup?

You _cannot_ perform case insensitive lookup without an upcase table by
definition of what case insensitive means.  attr_find/lookup _have_ to
do case insensitive comparison of the name.  They cannot do this if no
upcase table is present.

As I said in earlier message the correct fix would be to add either the
volume or the upcase table + length to somewhere, either the search
context itself so there would be "ntfs_inode_get_search_ctx(ntfs_inode
*ni)" and "ntfs_mft_get_search_ctx(ntfs_volume *vol, MFT_RECORD *mrec)".
Or alternatively modify ntfs_attr_find() to also take the upcase table
(or the volume I suppose but that will cause problems with places that
do not have a volume) and then you can pass it in when you have acquired
the context with (NULL, mrec)...

Basically ntfs_attr_find() MUST AT ALL TIMES have access to upcase table
if a name is provided for the comparisons.  At present if you get a
search context with (NULL, mrec) you do NOT have an upcase table in
_lookup/find so they cannot execute correctly.

Just read ntfs_attr_find():

if (name =3D=3D AT_UNNAMED) {
        /* The search failed if the found attribute is named. */
        if (a->name_length) {
                errno =3D ENOENT;
                return -1;
        }
} else if (name && !ntfs_names_are_equal(name, name_len,
            (ntfschar*)((char*)a + le16_to_cpu(a->name_offset)),
            a->name_length, ic, upcase, upcase_len)) {
        register int rc;

        rc =3D ntfs_names_collate(name, name_len,
                        (ntfschar*)((char*)a +
                        le16_to_cpu(a->name_offset)),
                        a->name_length, 1, IGNORE_CASE,
                        upcase, upcase_len);


************************************
THIS REQUIRES UPCASE TABLE
************************************


        /*
         * If @name collates before a->name, there is no
         * matching attribute.
         */
        if (rc =3D=3D -1) {
                errno =3D ENOENT;
                return -1;
        }
        /* If the strings are not equal, continue search. */
        if (rc)
                continue;
        rc =3D ntfs_names_collate(name, name_len,
                        (ntfschar*)((char*)a +
                        le16_to_cpu(a->name_offset)),
                        a->name_length, 1, CASE_SENSITIVE,
                        upcase, upcase_len);
        if (rc =3D=3D -1) {
                errno =3D ENOENT;
                return -1;
        }
        if (rc)
                continue;
}

Sorry but which part of this do you not understand?  What you were doing
worked only by chance/accident/coincidence.  It WOULD cause data
corruption and I am not having it.

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 / IRC: #ntfs on irc.freenode.net
WWW: http://linux-ntfs.sf.net/ & http://www-stu.christs.cam.ac.uk/~aia21/

[Linux-NTFS-Dev] Re: [Linux-NTFS-cvs] CVS: ntfsprogs/libntfs attrib.c,1.178,1.179

[Yura P. <y.p...@sa...>]

=D0=92 =D0=9F=D1=82=D0=BD, 30/09/2005 =D0=B2 11:02 +0100, Anton Altaparmako=
v =D0=BF=D0=B8=D1=88=D0=B5=D1=82:
> > --- attrib.c	28 Sep 2005 13:47:47 -0000	1.178
> > +++ attrib.c	30 Sep 2005 09:52:05 -0000	1.179
> > @@ -2554,7 +2554,7 @@ int ntfs_resident_attr_record_add(ntfs_i
> >  	}
> > =20
> >  	/* Locate place where record should be. */
> > -	ctx =3D ntfs_attr_get_search_ctx(ni, NULL);
> > +	ctx =3D ntfs_attr_get_search_ctx(NULL, ni->mrec);
> >  	if (!ctx)
> >  		return -1;
> >  	if (!ntfs_attr_lookup(type, name, name_len,
> > @@ -2679,7 +2679,7 @@ int ntfs_non_resident_attr_record_add(nt
> >  	}
> > =20
> >  	/* Locate place where record should be. */
> > -	ctx =3D ntfs_attr_get_search_ctx(ni, NULL);
> > +	ctx =3D ntfs_attr_get_search_ctx(NULL, ni->mrec);
> >  	if (!ctx)
> >  		return -1;
> >  	if (!ntfs_attr_lookup(type, name, name_len, CASE_SENSITIVE,
> > @@ -3342,7 +3342,7 @@ int ntfs_attr_record_move_to(ntfs_attr_s
> > =20
> >  	/* Find place in MFT record where attribute will be moved. */
> >  	a =3D ctx->attr;
> > -	nctx =3D ntfs_attr_get_search_ctx(ni, NULL);
> > +	nctx =3D ntfs_attr_get_search_ctx(NULL, ni->mrec);
> >  	if (!nctx) {
> >  		err =3D errno;
> >  		Dprintf("%s(): Couldn't obtain search context.\n",
>=20
> The above three will now always fail when name !=3D NULL in the call to
> ntfs_attr_lookup().  You must use ntfs_attr_find() instead.

Why you add such check? What problems can happen in case sensitive
lookup?

--=20
Best regards,
        Yura

[Linux-NTFS-Dev] Re: [Linux-NTFS-cvs] CVS: ntfsprogs/libntfs attrib.c,1.178,1.179

[Anton A. <ai...@ca...>]

On Fri, 2005-09-30 at 11:04 +0100, Anton Altaparmakov wrote:
> On Fri, 2005-09-30 at 11:02 +0100, Anton Altaparmakov wrote:
> > Hi Yura,
> > 
> > On Fri, 2005-09-30 at 02:52 -0700, Yura Pakhuchiy wrote:
> > > Changes by: cha0smaster
> > > 
> > > Update of /cvsroot/linux-ntfs/ntfsprogs/libntfs
> > > In directory sc8-pr-cvs1.sourceforge.net:/tmp/cvs-serv3398/libntfs
> > > 
> > > Modified Files:
> > > 	attrib.c 
> > > Log Message:
> > > Revert Anton's code that breaks functions needed for attribute resize.
> > > 
> > > 
> > > Index: attrib.c
> > > ===================================================================
> > > RCS file: /cvsroot/linux-ntfs/ntfsprogs/libntfs/attrib.c,v
> > > retrieving revision 1.178
> > > retrieving revision 1.179
> > > diff -u -p -r1.178 -r1.179
> > > --- attrib.c	28 Sep 2005 13:47:47 -0000	1.178
> > > +++ attrib.c	30 Sep 2005 09:52:05 -0000	1.179
> > > @@ -2554,7 +2554,7 @@ int ntfs_resident_attr_record_add(ntfs_i
> > >  	}
> > >  
> > >  	/* Locate place where record should be. */
> > > -	ctx = ntfs_attr_get_search_ctx(ni, NULL);
> > > +	ctx = ntfs_attr_get_search_ctx(NULL, ni->mrec);
> > >  	if (!ctx)
> > >  		return -1;
> > >  	if (!ntfs_attr_lookup(type, name, name_len,
> > > @@ -2679,7 +2679,7 @@ int ntfs_non_resident_attr_record_add(nt
> > >  	}
> > >  
> > >  	/* Locate place where record should be. */
> > > -	ctx = ntfs_attr_get_search_ctx(ni, NULL);
> > > +	ctx = ntfs_attr_get_search_ctx(NULL, ni->mrec);
> > >  	if (!ctx)
> > >  		return -1;
> > >  	if (!ntfs_attr_lookup(type, name, name_len, CASE_SENSITIVE,
> > > @@ -3342,7 +3342,7 @@ int ntfs_attr_record_move_to(ntfs_attr_s
> > >  
> > >  	/* Find place in MFT record where attribute will be moved. */
> > >  	a = ctx->attr;
> > > -	nctx = ntfs_attr_get_search_ctx(ni, NULL);
> > > +	nctx = ntfs_attr_get_search_ctx(NULL, ni->mrec);
> > >  	if (!nctx) {
> > >  		err = errno;
> > >  		Dprintf("%s(): Couldn't obtain search context.\n",
> > 
> > The above three will now always fail when name != NULL in the call to
> > ntfs_attr_lookup().  You must use ntfs_attr_find() instead.
> 
> And then they will still be broken since upcase and upcase_len will be
> NULL and 0 and ntfs_names_collate(IGNORE_CASE) will fail in
> ntfs_attr_find().

My initial code using ntfs_attr_get_search_ctx(ni, NULL) was correct.
It is just that you want to use ntfs_attr_find() instead of _lookup().

You complained ntfs_attr_find() is internal.  That is correct.  But you
are writing internal code!  Internal code is allowed to use internal
code...  Heck your functions are even in the same file so _find can
still remain static!

Best regards,

        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/

[Linux-NTFS-Dev] Re: [Linux-NTFS-cvs] CVS: ntfsprogs/libntfs attrib.c,1.178,1.179

[Anton A. <ai...@ca...>]

On Fri, 2005-09-30 at 11:02 +0100, Anton Altaparmakov wrote:
> Hi Yura,
> 
> On Fri, 2005-09-30 at 02:52 -0700, Yura Pakhuchiy wrote:
> > Changes by: cha0smaster
> > 
> > Update of /cvsroot/linux-ntfs/ntfsprogs/libntfs
> > In directory sc8-pr-cvs1.sourceforge.net:/tmp/cvs-serv3398/libntfs
> > 
> > Modified Files:
> > 	attrib.c 
> > Log Message:
> > Revert Anton's code that breaks functions needed for attribute resize.
> > 
> > 
> > Index: attrib.c
> > ===================================================================
> > RCS file: /cvsroot/linux-ntfs/ntfsprogs/libntfs/attrib.c,v
> > retrieving revision 1.178
> > retrieving revision 1.179
> > diff -u -p -r1.178 -r1.179
> > --- attrib.c	28 Sep 2005 13:47:47 -0000	1.178
> > +++ attrib.c	30 Sep 2005 09:52:05 -0000	1.179
> > @@ -2554,7 +2554,7 @@ int ntfs_resident_attr_record_add(ntfs_i
> >  	}
> >  
> >  	/* Locate place where record should be. */
> > -	ctx = ntfs_attr_get_search_ctx(ni, NULL);
> > +	ctx = ntfs_attr_get_search_ctx(NULL, ni->mrec);
> >  	if (!ctx)
> >  		return -1;
> >  	if (!ntfs_attr_lookup(type, name, name_len,
> > @@ -2679,7 +2679,7 @@ int ntfs_non_resident_attr_record_add(nt
> >  	}
> >  
> >  	/* Locate place where record should be. */
> > -	ctx = ntfs_attr_get_search_ctx(ni, NULL);
> > +	ctx = ntfs_attr_get_search_ctx(NULL, ni->mrec);
> >  	if (!ctx)
> >  		return -1;
> >  	if (!ntfs_attr_lookup(type, name, name_len, CASE_SENSITIVE,
> > @@ -3342,7 +3342,7 @@ int ntfs_attr_record_move_to(ntfs_attr_s
> >  
> >  	/* Find place in MFT record where attribute will be moved. */
> >  	a = ctx->attr;
> > -	nctx = ntfs_attr_get_search_ctx(ni, NULL);
> > +	nctx = ntfs_attr_get_search_ctx(NULL, ni->mrec);
> >  	if (!nctx) {
> >  		err = errno;
> >  		Dprintf("%s(): Couldn't obtain search context.\n",
> 
> The above three will now always fail when name != NULL in the call to
> ntfs_attr_lookup().  You must use ntfs_attr_find() instead.

And then they will still be broken since upcase and upcase_len will be
NULL and 0 and ntfs_names_collate(IGNORE_CASE) will fail in
ntfs_attr_find().

Best regards,

        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/

[Linux-NTFS-Dev] Re: [Linux-NTFS-cvs] CVS: ntfsprogs/libntfs attrib.c,1.178,1.179

[Anton A. <ai...@ca...>]

Hi Yura,

On Fri, 2005-09-30 at 02:52 -0700, Yura Pakhuchiy wrote:
> Changes by: cha0smaster
> 
> Update of /cvsroot/linux-ntfs/ntfsprogs/libntfs
> In directory sc8-pr-cvs1.sourceforge.net:/tmp/cvs-serv3398/libntfs
> 
> Modified Files:
> 	attrib.c 
> Log Message:
> Revert Anton's code that breaks functions needed for attribute resize.
> 
> 
> Index: attrib.c
> ===================================================================
> RCS file: /cvsroot/linux-ntfs/ntfsprogs/libntfs/attrib.c,v
> retrieving revision 1.178
> retrieving revision 1.179
> diff -u -p -r1.178 -r1.179
> --- attrib.c	28 Sep 2005 13:47:47 -0000	1.178
> +++ attrib.c	30 Sep 2005 09:52:05 -0000	1.179
> @@ -2554,7 +2554,7 @@ int ntfs_resident_attr_record_add(ntfs_i
>  	}
>  
>  	/* Locate place where record should be. */
> -	ctx = ntfs_attr_get_search_ctx(ni, NULL);
> +	ctx = ntfs_attr_get_search_ctx(NULL, ni->mrec);
>  	if (!ctx)
>  		return -1;
>  	if (!ntfs_attr_lookup(type, name, name_len,
> @@ -2679,7 +2679,7 @@ int ntfs_non_resident_attr_record_add(nt
>  	}
>  
>  	/* Locate place where record should be. */
> -	ctx = ntfs_attr_get_search_ctx(ni, NULL);
> +	ctx = ntfs_attr_get_search_ctx(NULL, ni->mrec);
>  	if (!ctx)
>  		return -1;
>  	if (!ntfs_attr_lookup(type, name, name_len, CASE_SENSITIVE,
> @@ -3342,7 +3342,7 @@ int ntfs_attr_record_move_to(ntfs_attr_s
>  
>  	/* Find place in MFT record where attribute will be moved. */
>  	a = ctx->attr;
> -	nctx = ntfs_attr_get_search_ctx(ni, NULL);
> +	nctx = ntfs_attr_get_search_ctx(NULL, ni->mrec);
>  	if (!nctx) {
>  		err = errno;
>  		Dprintf("%s(): Couldn't obtain search context.\n",

The above three will now always fail when name != NULL in the call to
ntfs_attr_lookup().  You must use ntfs_attr_find() instead.

Best regards,

        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/

Re: [Linux-NTFS-Dev] Status of rename() and unlink()?

[Yuval <yu...@gm...>]

On 9/29/05, Klaus Knopper wrote:
> Hello,
>
> Just asking, is there any chance to get unlimited rename() and/or
> unlink() capabilities in the library which can be used with fuse, within
> the next week or so?
[...]
> Unfortunately rename() does not seem to be implemented yet. We probably
> only need reliable file renaming within the same directory (like in mv
> file file.bak, which probably doesn't require any complicated tree belanc=
ings),
> not moving files between directories.

rename() was actually commited a week ago (24 september) by Yura:
https://sourceforge.net/mailarchive/forum.php?thread_id=3D8289385&forum_id=
=3D44768
https://sourceforge.net/mailarchive/forum.php?thread_id=3D8289386&forum_id=
=3D44768

Bare in mind that rename() is actually both link and unlink and
therefore has higher chance of failing. Either that or you were using
an older CVS.

Sincerely
-- Yuval

Re: [Linux-NTFS-Dev] status of new website?

[Yuval <yu...@gm...>]

On 9/29/05, Yura Pakhuchiy wrote:
> On Thu, 2005-09-29 at 21:43 +0200, Yuval wrote:
> > On 9/29/05, Yura Pakhuchiy wrote:
> > > Also there are no man pages for utils on new site, only links to not
> > > existing pages.
> >
> > I changed the links to the corresponding wiki pages, and continued to
> > fill up these pages.
>
> Cool! But maybe provide 2 links: to man page and to wiki page?

I thought about it, and *I* won't do it at the moment.
The reason is that the man pages deserve some touch, and mine is busy
at the moment.
If someone wants to re-convert (and maybe verifying the text on the
fly) the CVS man pages to html (or to docbook, and from there to man
and html), ping me. (There are some automatic tools, but like no one
that I could find)

> BTW, pages from development section in CMS all present in wiki, maybe
> merge information from wiki and CMS, and put link to wiki instead of
> having 2 separate pages for single thing?

The contents are different, and were written for different purposes,
Although I do agree that in retrospect, they seem too similar.

Also, some pages can not (or very difficult, see the FAQ) be stored in
the wiki, but easily stored as raw HTML which is allowed in the CMS.

I'm waiting for Darwin to decide which one will survive.

Sincerely
-- Yuval

[Linux-NTFS-Dev] Status of rename() and unlink()?

[Klaus K. <lin...@kn...>]

Hello,

Just asking, is there any chance to get unlimited rename() and/or
unlink() capabilities in the library which can be used with fuse, within
the next week or so?

Background: There is a new Knoppix-based (Windows-)virus removal tool
ahead. All we will probably need is stable removing and renaming of
files. Maybe also overwrites, but that part seems to work already with
the CVS version.

Since the virus checkers in question will try to access a mounted
filesystem rather than calling individual ntfs-utilities, the
ntfsmount/fuse thing would be a great step forward, and an alternative
to the proprietary Paragon NTFS driver.

Unfortunately rename() does not seem to be implemented yet. We probably
only need reliable file renaming within the same directory (like in mv
file file.bak, which probably doesn't require any complicated tree belancings),
not moving files between directories.

Regards
-Klaus Knopper

Re: [Linux-NTFS-Dev] status of new website?

[Yura P. <pak...@ip...>]

On Thu, 2005-09-29 at 21:43 +0200, Yuval wrote:
> On 9/29/05, Yura Pakhuchiy wrote:
> > Also there are no man pages for utils on new site, only links to not
> > existing pages.
> 
> I changed the links to the corresponding wiki pages, and continued to
> fill up these pages.

Cool! But maybe provide 2 links: to man page and to wiki page?

BTW, pages from development section in CMS all present in wiki, maybe
merge information from wiki and CMS, and put link to wiki instead of
having 2 separate pages for single thing?

-- 
Best regards,
        Yura

Re: [Linux-NTFS-Dev] status of new website?

[Anton A. <ai...@ca...>]

On Thu, 29 Sep 2005, Yuval wrote:
> On 9/29/05, mar...@gm... <mar...@gm...> wrote:
> > Anton Altaparmakov wrote:
> > > What is the status of the new website?  Is it ready to become the master
> > > site?  If not what is the current ETA?  (Doesn't have to be accurate, just
> > > the current random value of the day...)
> >
> > The main thing missing is email notification for the forum. I planned to
> > integrate it by last weekend, but currently have too much work in my 'real'
> > job. I think email notification is neccessary so we don't have to check the
> > forums for new posts regularly. Unless we find a forum moderator, so to say.
> > (*Any newbies want to join and become a moderator right away???* :-) )
> >
> > Some smaller things are missing too, I want to put a backup copy on SF,
> > for example, but these are more straight-forward.
> > Since I have a completely free Saturday, if all goes well the new ETA for
> > the page release is Sunday.
> 
> What about some page to replace http://linux-ntfs.sourceforge.net/rpm/ ?
> We link to that page from http://www.linux-ntfs.org/content/view/19/37/
> (I don't mind to forward to the existing page for now and redesign it
> a bit later)

You can't do that.  The existing pages will no longer exist once we switch 
over, i.e. linux-ntfs.sf.net will point to www.linux-ntfs.org...  (Or at 
least that is how I understand it works, I may be completely wrong 
though.  I just assume that once I (or whoever) switches the "Project 
homepage" on SF.net to the new site this is what would happen but maybe I 
am completely wrong on that one...)

Best regards,

	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/

Re: [Linux-NTFS-Dev] status of new website?

[Yuval <yu...@gm...>]

On 9/29/05, Yura Pakhuchiy wrote:
> Also there are no man pages for utils on new site, only links to not
> existing pages.

I changed the links to the corresponding wiki pages, and continued to
fill up these pages.

Sincerely
-- Yuval

Re: [Linux-NTFS-Dev] status of new website?

[Yura P. <pak...@ip...>]

On Thu, 2005-09-29 at 20:36 +0200, Yuval wrote:
> On 9/29/05, mar...@gm... <mar...@gm...> wrote:
> > Hi,
> >
> > Anton Altaparmakov wrote:
> > > What is the status of the new website?  Is it ready to become the master
> > > site?  If not what is the current ETA?  (Doesn't have to be accurate, just
> > > the current random value of the day...)
> >
> > The main thing missing is email notification for the forum. I planned to
> > integrate it by last weekend, but currently have too much work in my 'real'
> > job. I think email notification is neccessary so we don't have to check the
> > forums for new posts regularly. Unless we find a forum moderator, so to say.
> > (*Any newbies want to join and become a moderator right away???* :-) )
> >
> > Some smaller things are missing too, I want to put a backup copy on SF,
> > for example, but these are more straight-forward.
> > Since I have a completely free Saturday, if all goes well the new ETA for
> > the page release is Sunday.
> 
> What about some page to replace http://linux-ntfs.sourceforge.net/rpm/ ?
> We link to that page from http://www.linux-ntfs.org/content/view/19/37/
> (I don't mind to forward to the existing page for now and redesign it
> a bit later)

Also there are no man pages for utils on new site, only links to not
existing pages.

-- 
Best regards,
        Yura

Re: [Linux-NTFS-Dev] status of new website?

[Yuval <yu...@gm...>]

On 9/29/05, mar...@gm... <mar...@gm...> wrote:
> Hi,
>
> Anton Altaparmakov wrote:
> > What is the status of the new website?  Is it ready to become the maste=
r
> > site?  If not what is the current ETA?  (Doesn't have to be accurate, j=
ust
> > the current random value of the day...)
>
> The main thing missing is email notification for the forum. I planned to
> integrate it by last weekend, but currently have too much work in my 'rea=
l'
> job. I think email notification is neccessary so we don't have to check t=
he
> forums for new posts regularly. Unless we find a forum moderator, so to s=
ay.
> (*Any newbies want to join and become a moderator right away???* :-) )
>
> Some smaller things are missing too, I want to put a backup copy on SF,
> for example, but these are more straight-forward.
> Since I have a completely free Saturday, if all goes well the new ETA for
> the page release is Sunday.

What about some page to replace http://linux-ntfs.sourceforge.net/rpm/ ?
We link to that page from http://www.linux-ntfs.org/content/view/19/37/
(I don't mind to forward to the existing page for now and redesign it
a bit later)

Re: [Linux-NTFS-Dev] status of new website?

[<mar...@gm...>]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1


Hi,

Anton Altaparmakov wrote:
> What is the status of the new website?  Is it ready to become the master 
> site?  If not what is the current ETA?  (Doesn't have to be accurate, just 
> the current random value of the day...)

The main thing missing is email notification for the forum. I planned to
integrate it by last weekend, but currently have too much work in my 'real'
job. I think email notification is neccessary so we don't have to check the
forums for new posts regularly. Unless we find a forum moderator, so to say.
(*Any newbies want to join and become a moderator right away???* :-) )

Some smaller things are missing too, I want to put a backup copy on SF,
for example, but these are more straight-forward.
Since I have a completely free Saturday, if all goes well the new ETA for
the page release is Sunday.

Cheers,
   Mario
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.1 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org

iD8DBQFDPDG8dr6lwuqb+oIRAh3UAJwKPbo6kxqBGECdg7n3RW/iaYBk0ACgiec0
L6G0/k7rA3/FYglLAQ/7rX8=
=8Nxz
-----END PGP SIGNATURE-----

Re: [Linux-NTFS-Dev] error in ntfsmount

[Anton A. <ai...@ca...>]

Hi,

On Thu, 29 Sep 2005, Jens Arm wrote:
> I have found a bug in ntfsmount and/or libntfs, perhaps with names which =
are nearly the same:
>=20
> I get an "operation not supported".
> I use newest cvs.
>=20
> I have to do to get the error:
>=20
> 1. create fs with mkntfs
> 2. mount it with: ntfsmount /home/tux/media/ntfs -o dev=3D/dev/sda1,succe=
ed_chmod
> 3. cd /home/tux/media/ntfs
> 4. mkdir test
> 5. cd test
> 6. touch 264832689khvIQa 348035721etiZZU 305540613SFQwUV 405740136TgfzsO =
440602278DYNWAB 426966314QlUQUx 264833286kqktve 248221352ZxcJwZ
>     here I get: touch: kann ,,248221352ZxcJwZ" nicht ber=FChren: Die Oper=
ation wird nicht unterst=FCtzt
> 7. ls -lsa
> tux@tux:~/media/ntfs/test$ ls -lsa
> insgesamt 0
> 0 drwx------  1 tux tux 0 2005-09-29 08:38 .
> 0 -rw-------  1 tux tux 0 2005-09-29 08:38 264832689khvIQa
> 0 -rw-------  1 tux tux 0 2005-09-29 08:38 264833286kqktve
> 0 -rw-------  1 tux tux 0 2005-09-29 08:38 305540613SFQwUV
> 0 -rw-------  1 tux tux 0 2005-09-29 08:38 348035721etiZZU
> 0 -rw-------  1 tux tux 0 2005-09-29 08:38 405740136TgfzsO
> 0 -rw-------  1 tux tux 0 2005-09-29 08:38 426966314QlUQUx
> 0 -rw-------  1 tux tux 0 2005-09-29 08:38 440602278DYNWAB
>=20
> Why the last file cannot be created ????
> Looks like there are problems with filenames which are equal at some poin=
t.
>=20
> I am not on the list, so please mail directly to me.

It is not a bug it is a feature.  ntfsmount and libntfs only support a=20
very restricted set of directory modifications.  So you just hit a case=20
that is not supported.  If you read the ntfsmount man page you will see:

<quote>
=09Partly implented features:
=09=09* Create/Delete/Move files and directories.
</quote>

I admit this probably ought to be described in more detail than that but=20
it does give you the hint that it is partly implemented...

Best regards,

=09Anton
--=20
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/

[Linux-NTFS-Dev] error in ntfsmount

[Jens A. <Jen...@gm...>]

Hi

I have found a bug in ntfsmount and/or libntfs, perhaps with names which ar=
e nearly the same:

I get an "operation not supported".
I use newest cvs.

I have to do to get the error:

1. create fs with mkntfs
2. mount it with: ntfsmount /home/tux/media/ntfs -o dev=3D/dev/sda1,succeed=
_chmod
3. cd /home/tux/media/ntfs
4. mkdir test
5. cd test
6. touch 264832689khvIQa 348035721etiZZU 305540613SFQwUV 405740136TgfzsO 44=
0602278DYNWAB 426966314QlUQUx 264833286kqktve 248221352ZxcJwZ
    here I get: touch: kann ,,248221352ZxcJwZ" nicht ber=FChren: Die Operat=
ion wird nicht unterst=FCtzt
7. ls -lsa
tux@tux:~/media/ntfs/test$ ls -lsa
insgesamt 0
0 drwx------  1 tux tux 0 2005-09-29 08:38 .
0 -rw-------  1 tux tux 0 2005-09-29 08:38 264832689khvIQa
0 -rw-------  1 tux tux 0 2005-09-29 08:38 264833286kqktve
0 -rw-------  1 tux tux 0 2005-09-29 08:38 305540613SFQwUV
0 -rw-------  1 tux tux 0 2005-09-29 08:38 348035721etiZZU
0 -rw-------  1 tux tux 0 2005-09-29 08:38 405740136TgfzsO
0 -rw-------  1 tux tux 0 2005-09-29 08:38 426966314QlUQUx
0 -rw-------  1 tux tux 0 2005-09-29 08:38 440602278DYNWAB

Why the last file cannot be created ????
Looks like there are problems with filenames which are equal at some point.

I am not on the list, so please mail directly to me.

cu Jens

Re: [Linux-NTFS-Dev] Re: Braindamaged names in NTFS?

[Yura P. <pak...@ip...>]

On Wed, 2005-09-28 at 17:36 +0300, Yura Pakhuchiy wrote:
> =D0=92 =D0=A1=D1=80=D0=B4, 28/09/2005 =D0=B2 15:09 +0100, Anton Altaparma=
kov =D0=BF=D0=B8=D1=88=D0=B5=D1=82:
> > Hi Yura,
> >=20
> > On Mon, 2005-09-26 at 19:41 +0300, Yura Pakhuchiy wrote:
> > > Hi Anton,
> > >=20
> > > [Forgot to CC:- to list first time, extended it a bit and resend.]
> > >=20
> > > Is it acceptable from ntfs.sys point of view to have following filena=
mes
> > > in the index:
> > > 	a (in WIN32_AND_DOS namespace)
> > > 	A (in POSIX namespace)?
> > >=20
> > > At present ntfs_create allow creating of such names, but then library
> > > work incorrectly with such names. What I need to fix ntfs_create or
> > > other parts of library?
> >=20
> > In what way does it work incorrectly?
> >=20
> > Windows does not allow you to create such names but that doesn't
> > necessarily mean that ntfs.sys is not happy with them.  It also depends
> > on your definition of "not happy".  NT4 was relatively easy to get to
> > crash when playing with such things...
>=20
> AFAIR ntfs_pathname_to_inode works incorrectly in this case, will look
> at home for more details.

It seems that I was wrong about it, only ntfs_delete works incorrectly.
Test file had got damaged, but I didn't noticed that and thought that
library works incorrectly. Sorry.

--=20
Best regards,
        Yura

[Linux-NTFS-Dev] status of new website?

[Anton A. <ai...@ca...>]

Hi Mario,

What is the status of the new website?  Is it ready to become the master 
site?  If not what is the current ETA?  (Doesn't have to be accurate, just 
the current random value of the day...)

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/

Re: [Linux-NTFS-Dev] I want to help too :)

[Yura P. <pak...@ip...>]

Hi Miguel,

On Wed, 2005-09-28 at 23:52 +0200, "Miguel A. Mu=C3=B1oz" wrote:
> I'm Miguel Angel and I'm new to the list. I want to help in linux-ntfs=20
> project. I'm a student of Computer Science in Granada, Spain. My=20
> interest is to become a kernel hacker (someday). I'm reading some books=20
> about the Linux kernel; for instance: "Linux Kernel Development", by=20
> Robert Love, "Understanding The Linux Kernel" or "Linux Device Drivers".=20
> I have a lot of experience in C/C++ and assembler on x86 (Intel syntax=20
> only).
>=20
> I need some help to start with the project, I don't know where to start.=20
> Can anybody help me? ;)

Thank you for offer. Here is some links that will be interesting for
you:

http://www.linux-ntfs.org/content/view/14/28/
http://wiki.linux-ntfs.org/doku.php?id=3Dgetinvolved
http://www.linux-ntfs.org/content/view/18/36/

--=20
Best regards,
        Yura

[Linux-NTFS-Dev] I want to help too :)

[<mi...@co...>]

Hello,

I'm Miguel Angel and I'm new to the list. I want to help in linux-ntfs 
project. I'm a student of Computer Science in Granada, Spain. My 
interest is to become a kernel hacker (someday). I'm reading some books 
about the Linux kernel; for instance: "Linux Kernel Development", by 
Robert Love, "Understanding The Linux Kernel" or "Linux Device Drivers". 
I have a lot of experience in C/C++ and assembler on x86 (Intel syntax 
only).

I need some help to start with the project, I don't know where to start. 
Can anybody help me? ;)

Thanks,
	
	Miguel Angel

Re: [Linux-NTFS-Dev] Wanna help

[Mario E. <mar...@gm...>]

Hi,

Martin Cyr wrote:
> *Hi,
> I'd like to know how I could be of any help. I have some knowledge of
> C/C++ (only did Win32 up to now, but willing learn), C#, Java, .NET,
> PHP, JSP, ASP, Web and such.
> *

Cool. There are lots of things to do:
 - hack around in the drivers and/or tools
 - testing and/or debugging
 - writing or improving documentation
 - hack php on the website

and probably many more I didn't think of.
What would be your main interrest? Do you want to become
a linux driver/kernel guru, or would you have more fun on
'public relations' (like documentation)? Or other?

Just write back to the list, people will get you startet.

Cheers,
  Mario

[Linux-NTFS-Dev] Resizing cluster size

[Giuseppe B. <bil...@ho...>]

Hello,

I'm not sure this is the right place to discuss this, but it sounds
like the best one, so here it goes.

My system is a dual-boot Windows XP Pro/Debian Linux (unstable). Some
time ago I had to change my hard disk since the old one was failing,
but I still have it around for temporary storage matters and similar
stuff.

Recently, I chose to use it for testing some things, and of these was
cluster-resizing on NTFS paritions (from 4K to 1K clusters). I did it
using Powerquest's PartitionMagic 8.0 for Windows, and due to a
(known) bug in the program, the cluster-resizing aborted before the
process was complete, although most of it was done. The obvious net
result was an essentially unusable partition --apparently. Checking it
reported an obviously enormous amount of errors, and there was no way
to tell PM that this was due to an incomplete change.

I tried mounting it under Linux (2.6.12-1 from the aforementioned
Debian/unstable), but I managed to do it only after running ntfsfix.
Interestingly, however, much of the data was recoverable. I haven't
actually checked it all, but from the sound of it I could have
probabyl tried a full backup. I only retrieved the stuff I was
interested in, though.

The interesting part is that when the Windows NTFS disk checker tried
to "fix" the partition later on, it actually fouled things up even
worse, destroying the recoverability changes of some of the files I
had already backed up.

Concluding this over-verbose post, I was wondering:

* is there an ntfsprog that supports cluster-resizing? Does it work
even with compressed and/or sparse files?

* if yes, does it support error-recovery?

Considering that these programs are often used in recovery system,
such a feature would be a very strong point ...



-- 
Giuseppe "Oblomov" Bilotta

Axiom I of the Giuseppe Bilotta
theory of IT:
Anything is better than MS