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

[Linux-NTFS-Dev] ntfswipe status

[Alessandro V. <vol...@fa...>]

++ I AM NEW TO THE LIST !

Hi,

after installing ntfsprogs from the tar ball I did not find the ntfswipe 
application and its man-pages.

I went back to the installation directory and issued the commands "make 
extra" and "make install" . The latter command reinstalled the standard 
ntfsprogs executables in /usr/local/sbin ; ntfswipe was not installed.

I manually copied the ntfswipe executable (created by the "make extra" 
command) to the /usr/local/sbin directory and I was able to run it.

I AM VERY INTERESTED TO ntfswipe . I would like to use it after having 
accessed my trading-on-line account. My bank used a combination of java 
and javascript . The javascript part only works with MSIE and I am thus 
forced to work with Windows.

My only concern is : since ntfswipe is not included in the STANDARD 
ntfsprogs TOOL, it should be considered as AN EXPERIMENTAL APPLICATION ? 
Can I be reasonably confident it will work properly on a filesystem 
containing critical data ? I was not able to find information about 
ntfswipe PRESENT STATUS.

I would be very grateful to anyone who could tell me something about the 
issue.

Thanks and best regards.

Alessandro Volpi

Re: [Linux-NTFS-Dev] ntfs-3g bug: windows cannot access files written, but Linux can

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

On 7/30/06, amnesiac wrote:
> I only have one account on that machine, and that is the admin account.
>
> What's even stranger is the folder is said by the windows shell to be
> "emtpy." But that is clearly not the case since Linux can read from it just
> fine.

Can you send me a metadata image? A metadata image is a file that
contains the structure of your partition, and allows manual inspection
on what's wrong. It does not contain any content from your files.
Since it should be a snapshot of your partition, it should contain the
problematic file, and thus, it should allow me to locate the problem.

Creating the image is done by:
  ntfsclone --metadata --output ntfsmeta.img <your_ntfs_partition>
  bzip2 ntfsmeta.img

The resulting file should be small relativly to the partition. Please
email it to me in private (in order to not bomb mailing list
subscribers with files) or put it somewhere for download. If you need
a server to upload it to, say so, and it will be arranged.

More info on metadata images can be found on the ntfsclone wiki page:
http://wiki.linux-ntfs.org/doku.php?id=ntfsclone

Thanks
-- 
Yuval Fledel

Re: [Linux-NTFS-Dev] ntfs-3g bug: windows cannot access files written, but Linux can

[amnesiac <bla...@gm...>]

I only have one account on that machine, and that is the admin account.

What's even stranger is the folder is said by the windows shell to be
"emtpy." But that is clearly not the case since Linux can read from it just
fine.

On 7/29/06, Yuval Fledel <yu...@gm...> wrote:
>
> On 7/29/06, amnesiac wrote:
> > Hi, I used ntfs-3g to write a folder with mp3 files inside it onto my XP
> > partition. They can be accessed from Linux just fine, both through
> ntfs-3g
> > and the standard NTFS driver in the kernel, but in windows all I ever
> get is
> > "Access is denied." when trying to open the folder. I tried killing
> explorer
> > and cd'ing on over to the directory via cmd.exe, but that doesnt help --
> > same story, access is denied. I am not aware of any ntfs bugzilla so I
> > report this here. What kind of information would be helpful to you guys?
> >
> > Perhaps more importantly, also, is that the apparently corrupt write has
> > made another folder in the same directory inaccessible -- well, it is
> > accessible, but all the mp3s in the folder exhibit the same behavior,
> access
> > is denied when trying to open them.
>
> I believe that this is a known documented issue of ntfs-3g.
>
> Only Administrators can access files created by ntfs-3g.
>
> Both ntfs-3g and the ntfs kernel driver ignore permissions, but Windows
> don't.
>
> Do you work as an Administrator? If you do, say so and we'll guide you
> further. If not, log in as one and give your usual user full access to
> the files.
>
> --
> Yuval Fledel
>

Re: [Linux-NTFS-Dev] ntfs-3g bug: windows cannot access files written, but Linux can

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

On 7/29/06, amnesiac wrote:
> Hi, I used ntfs-3g to write a folder with mp3 files inside it onto my XP
> partition. They can be accessed from Linux just fine, both through ntfs-3g
> and the standard NTFS driver in the kernel, but in windows all I ever get is
> "Access is denied." when trying to open the folder. I tried killing explorer
> and cd'ing on over to the directory via cmd.exe, but that doesnt help --
> same story, access is denied. I am not aware of any ntfs bugzilla so I
> report this here. What kind of information would be helpful to you guys?
>
> Perhaps more importantly, also, is that the apparently corrupt write has
> made another folder in the same directory inaccessible -- well, it is
> accessible, but all the mp3s in the folder exhibit the same behavior, access
> is denied when trying to open them.

I believe that this is a known documented issue of ntfs-3g.

Only Administrators can access files created by ntfs-3g.

Both ntfs-3g and the ntfs kernel driver ignore permissions, but Windows don't.

Do you work as an Administrator? If you do, say so and we'll guide you
further. If not, log in as one and give your usual user full access to
the files.

-- 
Yuval Fledel

[Linux-NTFS-Dev] ntfs-3g bug: windows cannot access files written, but Linux can

[amnesiac <bla...@gm...>]

Hi, I used ntfs-3g to write a folder with mp3 files inside it onto my XP
partition. They can be accessed from Linux just fine, both through ntfs-3g
and the standard NTFS driver in the kernel, but in windows all I ever get is
"Access is denied." when trying to open the folder. I tried killing explorer
and cd'ing on over to the directory via cmd.exe, but that doesnt help --
same story, access is denied. I am not aware of any ntfs bugzilla so I
report this here. What kind of information would be helpful to you guys?

Perhaps more importantly, also, is that the apparently corrupt write has
made another folder in the same directory inaccessible -- well, it is
accessible, but all the mp3s in the folder exhibit the same behavior, access
is denied when trying to open them.

Re: [Linux-NTFS-Dev] [Linux-NTFS-cvs] CVS: ntfsprogs ChangeLog, 1.390, 1.391

[Mario E. <ma...@em...>]

Hi,

anything I need to do about this?

Cheers,
  Mario

Yura Pakhuchiy schrieb:
> Hi Anton,
> 
> On Mon, 24 Jul 2006 at 10:59 +0200, Anton Altaparmakov wrote:
>> Changes by: aia21
>>
>> Update of /cvs/linux-ntfs/ntfsprogs
>> In directory delta357.server4you.de:/tmp/cvs-serv2289
>>
>> Modified Files:
>> 	ChangeLog 
>> Log Message:
>> Hopefully final test.
> 
> It seems your tests had broken CVS mail notifications. :-(
> I quoted the last message I received.
> 

Re: [Linux-NTFS-Dev] [Linux-NTFS Forum: Usage Problems] RE: Large files - slow

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

On 7/25/06, Anton Altaparmakov wrote:
> > For comparison, coping a large file from one ntfs partition mounted
> > using the kernel driver to another ntfs partition mounted using
> > ntfs-3g copied ~142MB in 5:19 minutes. (actual size on disk: 134MB):
> > real    5m18.255s
> > user    0m0.028s
> > sys     0m0.728s
>
> And how about with the kernel driver as destination?  (Just do "touch
> destination" mounting with ntfs-3g, then unmount, mount with kernel driver
> and do the copy.)

I get "dd: writing to `file': Operation not supported" (on the upside,
the times are really good now)
It also happens on a file that was created in Windows (which is not
marked as sparse)

Debian stock kernel 2.6.16-17
NTFS kernel driver 2.1.26 [R/W]

dmesg explains (for both inodes):
ntfs_attr_extend_allocation(): Not enough space in the mft record for
the extended attribute record. This case is not implemented yet.

-- 
Sincerely
Yuval Fledel

Re: [Linux-NTFS-Dev] [announcement] ntfs-3g: open source read-write driver

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

On Thu, 27 Jul 2006 at 09:52 +0100, Anton Altaparmakov wrote:
> Argh.  You do evil things!  (-;  It now works again but please note that
> I believe what you do still is have a bug and will randomly cause
> corruption of the attribute list attribute because the attribute list
> entries will be sorted incorrectly.  Basically if SFU was a file rather
> than a directory and you instead of renaming it added hard links to it
> you would find that at least some of the hard links are incorrectly
> ordered in the attribute list attribute.  (It would be a complete per
> chance event as to which will go where.)  This is arguably a bug in
> ntfs_external_attr_find() or it could be argued to be a bug of
> ntfs_attrlist_entry_add().

Why attributes list can be sorted incorrectly? AFAIR you suggested me to
rewrite ntfs_attrlist_entry_add using ntfs_attr_lookup to find correct
place for new entry. ntfs_attr_lookup does not guarantee that attribute
list entry will be placed to the correct place anymore?

> Also I think you have a potential bug in that you add the attribute to
> the mft record before you have added it to the attribute list attribute
> and then you call ntfs_attr_lookup() on what effectively is a corrupt
> inode.  The only reason this works is a complete pure chance/luck and
> stronger sanity checking would make this code break...

I think that the best solution will be to return to old algorithm in the
ntfs_attrlist_entry_add (that does not use ntfs_attr_lookup). Attribute
list will be sorted by:
     1. Number
     2. Name
     3. Instance number (for resident attributes) and lowest VCN (for
        non-resident attributes)
This is correct algorithm?

-- 
Best regards,
        Yura

Re: [Linux-NTFS-Dev] [Linux-NTFS-cvs] CVS: ntfsprogs/libntfs runlist.c, 1.68, 1.69

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

On Thu, 27 Jul 2006, Yura Pakhuchiy wrote:
> Modified Files:
> 	runlist.c 
> Log Message:
> commit some fix to runlsi handling code from ntfs-3g
> Rich/Anton can you please review it?

Looks fine.

> Index: runlist.c
> ===================================================================
> RCS file: /cvs/linux-ntfs/ntfsprogs/libntfs/runlist.c,v
> retrieving revision 1.68
> retrieving revision 1.69
> diff -u -p -r1.68 -r1.69
> --- runlist.c	8 Feb 2006 22:15:30 -0000	1.68
> +++ runlist.c	27 Jul 2006 18:12:23 -0000	1.69
> @@ -3,6 +3,7 @@
>   *
>   * Copyright (c) 2002-2005 Anton Altaparmakov
>   * Copyright (c) 2002-2005 Richard Russon
> + * Copyright (c) 2002-2006 Szabolcs Szakacsits
>   * Copyright (c) 2004 Yura Pakhuchiy
>   *
>   * This program/include file is free software; you can redistribute it and/or
> @@ -1580,73 +1581,64 @@ err_out:
>  int ntfs_rl_truncate(runlist **arl, const VCN start_vcn)
>  {
>  	runlist *rl;
> -	BOOL is_end;
> +	BOOL is_end = FALSE;
>  
>  	if (!arl || !*arl) {
>  		errno = EINVAL;
> +		ntfs_log_perror("rl_truncate error: arl: %p *arl: %p", arl, *arl);
>  		return -1;
>  	}
> +	
>  	rl = *arl;
> +	
>  	if (start_vcn < rl->vcn) {
> -		// FIXME: Eeek! BUG()
> -		ntfs_log_trace("Eeek! start_vcn lies outside front of runlist!  "
> -				"Aborting.\n");
> -		errno = EIO;
> +		errno = EINVAL;
> +		ntfs_log_perror("Start_vcn lies outside front of runlist");
>  		return -1;
>  	}
> +	
>  	/* Find the starting vcn in the run list. */
>  	while (rl->length) {
>  		if (start_vcn < rl[1].vcn)
>  			break;
>  		rl++;
>  	}
> +	
>  	if (!rl->length) {
> -		// FIXME: Weird, probably a BUG()!
> -		ntfs_log_trace("Weird!  Asking to truncate already truncated "
> -				"runlist?!?  Abort.\n");
> -		errno = EIO;
> -		return -1;
> -	}
> -	if (start_vcn < rl->vcn) {
> -		// FIXME: Eeek! BUG()
> -		ntfs_log_trace("Eeek!  start_vcn < rl->vcn!  Aborting.\n");
>  		errno = EIO;
> +		ntfs_log_trace("Truncating already truncated runlist?\n");
>  		return -1;
>  	}
> +	
> +	/* Truncate the run. */
> +	rl->length = start_vcn - rl->vcn;
> +	
> +	/*
> +	 * If a run was partially truncated, make the following runlist
> +	 * element a terminator instead of the truncated runlist
> +	 * element itself.
> +	 */
>  	if (rl->length) {
> -		is_end = FALSE;
> -		/* Truncate the run. */
> -		rl->length = start_vcn - rl->vcn;
> -		/*
> -		 * If a run was partially truncated, make the following runlist
> -		 * element a terminator instead of the truncated runlist
> -		 * element itself.
> -		 */
> -		if (rl->length) {
> -			++rl;
> -			if (!rl->length)
> -				is_end = TRUE;
> -			rl->vcn = start_vcn;
> -			rl->length = 0;
> -		}
> -	} else
> -		is_end = TRUE;
> +		++rl;
> +		if (!rl->length)
> +			is_end = TRUE;
> +		rl->vcn = start_vcn;
> +		rl->length = 0;
> +	}
>  	rl->lcn = (LCN)LCN_ENOENT;
> -	/* Reallocate memory if necessary. */
> -	if (!is_end) {
> +	/**
> +	 * Reallocate memory if necessary.
> +	 * FIXME: Below code is broken, because runlist allocations must be 
> +	 * a multiply of 4096. The code caused crashes and corruptions.
> +	 */
> +/*	
> +	 if (!is_end) {
>  		size_t new_size = (rl - *arl + 1) * sizeof(runlist_element);
>  		rl = realloc(*arl, new_size);
>  		if (rl)
>  			*arl = rl;
> -		else if (!new_size)
> -			*arl = NULL;
> -		else {
> -			// FIXME: Eeek!
> -			ntfs_log_trace("Eeek!  Failed to reallocate runlist buffer!  "
> -				"Continuing regardless and returning success.\n");
> -		}
>  	}
> -	/* Done! */
> +*/
>  	return 0;
>  }

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, http://www.linux-ntfs.org/

Re: [Linux-NTFS-Dev] [Linux-NTFS Forum: Usage Problems] RE: Large files - slow

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

On Fri, 2006-07-28 at 11:26 +0200, Yuval Fledel wrote:
> On 7/25/06, Anton Altaparmakov wrote:
> > > For comparison, coping a large file from one ntfs partition mounted
> > > using the kernel driver to another ntfs partition mounted using
> > > ntfs-3g copied ~142MB in 5:19 minutes. (actual size on disk: 134MB):
> > > real    5m18.255s
> > > user    0m0.028s
> > > sys     0m0.728s
> >
> > And how about with the kernel driver as destination?  (Just do "touch
> > destination" mounting with ntfs-3g, then unmount, mount with kernel driver
> > and do the copy.)
> 
> I get "dd: writing to `file': Operation not supported" (on the upside,
> the times are really good now)
> It also happens on a file that was created in Windows (which is not
> marked as sparse)
> 
> Debian stock kernel 2.6.16-17
> NTFS kernel driver 2.1.26 [R/W]
> 
> dmesg explains (for both inodes):
> ntfs_attr_extend_allocation(): Not enough space in the mft record for
> the extended attribute record. This case is not implemented yet.

Ah, yes, that makes sense actually.  The above kernel driver does not
have the support for the attribute list attribute so it only managed to
extend the file until the mapping pairs array became too big to fit in
the mft record...

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://www.linux-ntfs.org/ & http://www-stu.christs.cam.ac.uk/~aia21/

Re: [Linux-NTFS-Dev] [Linux-NTFS-cvs] CVS: ntfsprogs ChangeLog, 1.390, 1.391

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

On Thu, 2006-07-27 at 23:24 +0300, Yura Pakhuchiy wrote:
> Hi Anton,
> 
> On Mon, 24 Jul 2006 at 10:59 +0200, Anton Altaparmakov wrote:
> > Changes by: aia21
> > 
> > Update of /cvs/linux-ntfs/ntfsprogs
> > In directory delta357.server4you.de:/tmp/cvs-serv2289
> > 
> > Modified Files:
> > 	ChangeLog 
> > Log Message:
> > Hopefully final test.
> 
> It seems your tests had broken CVS mail notifications. :-(
> I quoted the last message I received.

Not broken, no.  The list is just moderated now as Yuval complained
about spam coming in from it...

This morning when I checked it I added your cvs commit email address as
an accepted sender so your commits should now show up immediately.

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://www.linux-ntfs.org/ & http://www-stu.christs.cam.ac.uk/~aia21/

Re: [Linux-NTFS-Dev] [announcement] ntfs-3g: open source read-write driver

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

On Wed, 2006-07-26 at 17:58 +0300, Yura Pakhuchiy wrote:
> Hi Anton,
> 
> On Sun, 23 Jul 2006 at 22:49 +0100, Anton Altaparmakov wrote:
> > On Sun, 23 Jul 2006, Yura Pakhuchiy wrote:
> > > On Sun, 23 Jul 2006 at 08:33 +0300, Yura Pakhuchiy wrote:
> > > > On Sat, 15 Jul 2006 at 20:46 +0100, Anton Altaparmakov wrote:
> > > > > > > > Problem:    "No such file or directory" message when accessing some files:
> > > > > > > > Answer:     This is a known problem in libntfs inode attribute enumeration 
> > > > > > > >             when the same type of attributes are distributed across
> > > > > > > >             multiply mft records. Occures only very rarely.
> > > > > > > > Workaround: If the file is a hard link (usually yes) then first delete
> > > > > > > >             some other files hard linking to the same file then you'll
> > > > > > > >             be able to delete the problematic file as well.
> > > > > > > > Status:     High priority work.
> > > > > > > 
> > > > > > > Interesting.  This is the first time I hear of this problem.  Why did you 
> > > > > > > not report it?  Do you have an example where this happens?
> > > > > > 
> > > > > > I identified this problem before yesterday. Sometimes I can reproduce it by
> > > > > > 
> > > > > > 	cp -a /usr ntfs_volume
> > > > > > 	rm -rf ntfs_volume/usr
> > > > > > 
> > > > > > Most ntfs volumes have also such cases usually, so if you rm -rf / then you 
> > > > > > can find them easily. 
> > > > > 
> > > > > Weird.  I wonder if it is something libntfs specific and not in the 
> > > > > kernel as I have never seen this problem...
> > > > 
> > > > This is kernel driver problem too. It seems our knowledge about
> > > > attribute list a bit incorrect. ntfs_external_attr_find written in mind
> > > > with that attributes in the MFT record follow in same order as they
> > > > follow in attribute list. Metadata (link to which I send in previous
> > > > email) demonstrates vice-versa. FILE_NAME attributes follow in order 2,
> > > > 3 (instance numbers) in the attribute list, but 3, 2 in the MFT record.
> > 
> > You are correct that instance numbers are in sequence in attribute list 
> > attribute and are not in order in the mft record.  This is because the 
> > sequence numbers are used for collation in the attribute list attribute 
> > and they are not used for collation in the mft record (instead the 
> > attribute value is used which in case of the file name attribute means 
> > that the sequence number is irrelevant and the name is relevant instead).
> > 
> > What I don't understand is how that is causing file not found problems...
> > 
> > /me reads through ntfs_external_attr_find().
> > 
> > /me sees stupendously stupid bug and bashes head against wall repeatedly.
> > 
> > /me fixes bug and commits it to ntfsprogs.
> > 
> > I cannot believe this has not been found earlier!  This bug has been there 
> > since I originally wrote ntfs_external_attr_find() which was quite a few 
> > years ago now!  Amazing!
> 
> This bug fix introduced new bug to ntfs_external_attr_find. :-(
> 
> Metadata that illustrates problem:
> http://data.linux-ntfs.org/attr_lookup_bug2.img.bz2
> 
> Mount it with ntfsmount and try to rename directory "SFU" to another
> name. ntfs_external_attr_find will complain about damaged inode
> (Probably you know, but for any case, you can receive debug output from
> ntfsmount using "-o debug"). Reverting your last patch makes it happy.
> Please, fix!

Argh.  You do evil things!  (-;  It now works again but please note that
I believe what you do still is have a bug and will randomly cause
corruption of the attribute list attribute because the attribute list
entries will be sorted incorrectly.  Basically if SFU was a file rather
than a directory and you instead of renaming it added hard links to it
you would find that at least some of the hard links are incorrectly
ordered in the attribute list attribute.  (It would be a complete per
chance event as to which will go where.)  This is arguably a bug in
ntfs_external_attr_find() or it could be argued to be a bug of
ntfs_attrlist_entry_add().

Also I think you have a potential bug in that you add the attribute to
the mft record before you have added it to the attribute list attribute
and then you call ntfs_attr_lookup() on what effectively is a corrupt
inode.  The only reason this works is a complete pure chance/luck and
stronger sanity checking would make this code break...

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://www.linux-ntfs.org/ & http://www-stu.christs.cam.ac.uk/~aia21/

Re: [Linux-NTFS-Dev] [Linux-NTFS-cvs] CVS: ntfsprogs ChangeLog, 1.390, 1.391

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

Hi Anton,

On Mon, 24 Jul 2006 at 10:59 +0200, Anton Altaparmakov wrote:
> Changes by: aia21
> 
> Update of /cvs/linux-ntfs/ntfsprogs
> In directory delta357.server4you.de:/tmp/cvs-serv2289
> 
> Modified Files:
> 	ChangeLog 
> Log Message:
> Hopefully final test.

It seems your tests had broken CVS mail notifications. :-(
I quoted the last message I received.

-- 
Best regards,
        Yura

Re: [Linux-NTFS-Dev] [announcement] ntfs-3g: open source read-write driver

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

On Thu, 27 Jul 2006, Yura Pakhuchiy wrote:
> On Thu, 27 Jul 2006 at 09:52 +0100, Anton Altaparmakov wrote:
> > Argh.  You do evil things!  (-;  It now works again but please note that
> > I believe what you do still is have a bug and will randomly cause
> > corruption of the attribute list attribute because the attribute list
> > entries will be sorted incorrectly.  Basically if SFU was a file rather
> > than a directory and you instead of renaming it added hard links to it
> > you would find that at least some of the hard links are incorrectly
> > ordered in the attribute list attribute.  (It would be a complete per
> > chance event as to which will go where.)  This is arguably a bug in
> > ntfs_external_attr_find() or it could be argued to be a bug of
> > ntfs_attrlist_entry_add().
> 
> Why attributes list can be sorted incorrectly? AFAIR you suggested me to
> rewrite ntfs_attrlist_entry_add using ntfs_attr_lookup to find correct
> place for new entry. ntfs_attr_lookup does not guarantee that attribute
> list entry will be placed to the correct place anymore?

Yes, I think the function does not do the right thing in all cases as it 
is at the moment.  It only does things 100% correct for the non-attribute 
list attribute case.

> > Also I think you have a potential bug in that you add the attribute to
> > the mft record before you have added it to the attribute list attribute
> > and then you call ntfs_attr_lookup() on what effectively is a corrupt
> > inode.  The only reason this works is a complete pure chance/luck and
> > stronger sanity checking would make this code break...
> 
> I think that the best solution will be to return to old algorithm in the
> ntfs_attrlist_entry_add (that does not use ntfs_attr_lookup). Attribute

Perhaps.  Or perhaps best solution is to fix ntfs_attr_lookup()...

> list will be sorted by:
>      1. Number
>      2. Name
>      3. Instance number (for resident attributes) and lowest VCN (for
>         non-resident attributes)
> This is correct algorithm?

No, it cannot be sufficient.  For example you have two file names, one in 
the base mft record X and one in an extent mft record Y.  And both of 
those have independent instance numbers and say they are both equal to N.

So in the attribute list attribute you then have two identical entries 
with the same instance numbers and the only difference (AFAICS) is the mft 
record number to which they belong.

Currently ntfs_attr_lookup() will place any new ones after any existing 
ones (hence ordering is in fact random).

I imagine that Windows has a specific ordering requirement and thus we 
will get it wrong some of the time.

I am afraid this is such a corner case that I do not actually know the 
answer as to what is the correct ordering.

We will somehow need to experiment.  Perhaps by creating a file in Windows 
and making it have a really long file name and then creating lots and lots 
of hard links with really long names to it.  Then it will eventually end 
up in the situation when there will be lots of file names in each mft 
record and there will be lots of extent mft records.  And then look at the 
ordering in the attribute list attribute to see what Windows does.  And 
one better - reverse (using a hexeditor) the order of two of them by 
swapping the mft record references to two adjacent entries with the same 
instance number and then running chkdsk to see if it complains.  If it 
does complain then the order is important and this ordering needs to be 
added into ntfs_external_attr_find() and if it is not important then 
ntfs_attr_lookup() is fine and will always generate the correct result (I 
think - it may still get the sequence numbers wrong, need to double 
check)...

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, http://www.linux-ntfs.org/

Re: [Linux-NTFS-Dev] [announcement] ntfs-3g: open source read-write driver

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

Hi Anton,

On Sun, 23 Jul 2006 at 22:49 +0100, Anton Altaparmakov wrote:
> On Sun, 23 Jul 2006, Yura Pakhuchiy wrote:
> > On Sun, 23 Jul 2006 at 08:33 +0300, Yura Pakhuchiy wrote:
> > > On Sat, 15 Jul 2006 at 20:46 +0100, Anton Altaparmakov wrote:
> > > > > > > Problem:    "No such file or directory" message when accessing some files:
> > > > > > > Answer:     This is a known problem in libntfs inode attribute enumeration 
> > > > > > >             when the same type of attributes are distributed across
> > > > > > >             multiply mft records. Occures only very rarely.
> > > > > > > Workaround: If the file is a hard link (usually yes) then first delete
> > > > > > >             some other files hard linking to the same file then you'll
> > > > > > >             be able to delete the problematic file as well.
> > > > > > > Status:     High priority work.
> > > > > > 
> > > > > > Interesting.  This is the first time I hear of this problem.  Why did you 
> > > > > > not report it?  Do you have an example where this happens?
> > > > > 
> > > > > I identified this problem before yesterday. Sometimes I can reproduce it by
> > > > > 
> > > > > 	cp -a /usr ntfs_volume
> > > > > 	rm -rf ntfs_volume/usr
> > > > > 
> > > > > Most ntfs volumes have also such cases usually, so if you rm -rf / then you 
> > > > > can find them easily. 
> > > > 
> > > > Weird.  I wonder if it is something libntfs specific and not in the 
> > > > kernel as I have never seen this problem...
> > > 
> > > This is kernel driver problem too. It seems our knowledge about
> > > attribute list a bit incorrect. ntfs_external_attr_find written in mind
> > > with that attributes in the MFT record follow in same order as they
> > > follow in attribute list. Metadata (link to which I send in previous
> > > email) demonstrates vice-versa. FILE_NAME attributes follow in order 2,
> > > 3 (instance numbers) in the attribute list, but 3, 2 in the MFT record.
> 
> You are correct that instance numbers are in sequence in attribute list 
> attribute and are not in order in the mft record.  This is because the 
> sequence numbers are used for collation in the attribute list attribute 
> and they are not used for collation in the mft record (instead the 
> attribute value is used which in case of the file name attribute means 
> that the sequence number is irrelevant and the name is relevant instead).
> 
> What I don't understand is how that is causing file not found problems...
> 
> /me reads through ntfs_external_attr_find().
> 
> /me sees stupendously stupid bug and bashes head against wall repeatedly.
> 
> /me fixes bug and commits it to ntfsprogs.
> 
> I cannot believe this has not been found earlier!  This bug has been there 
> since I originally wrote ntfs_external_attr_find() which was quite a few 
> years ago now!  Amazing!

This bug fix introduced new bug to ntfs_external_attr_find. :-(

Metadata that illustrates problem:
http://data.linux-ntfs.org/attr_lookup_bug2.img.bz2

Mount it with ntfsmount and try to rename directory "SFU" to another
name. ntfs_external_attr_find will complain about damaged inode
(Probably you know, but for any case, you can receive debug output from
ntfsmount using "-o debug"). Reverting your last patch makes it happy.
Please, fix!

-- 
Best regards,
        Yura

Re: [Linux-NTFS-Dev] [announcement] ntfs-3g: open source read-write driver

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

On Sun, 23 Jul 2006 at 22:49 +0100, Anton Altaparmakov wrote:
> On Sun, 23 Jul 2006, Yura Pakhuchiy wrote:
> > On Sun, 23 Jul 2006 at 08:33 +0300, Yura Pakhuchiy wrote:
> > > On Sat, 15 Jul 2006 at 20:46 +0100, Anton Altaparmakov wrote:
> > > > > > > Problem:    "No such file or directory" message when accessing some files:
> > > > > > > Answer:     This is a known problem in libntfs inode attribute enumeration 
> > > > > > >             when the same type of attributes are distributed across
> > > > > > >             multiply mft records. Occures only very rarely.
> > > > > > > Workaround: If the file is a hard link (usually yes) then first delete
> > > > > > >             some other files hard linking to the same file then you'll
> > > > > > >             be able to delete the problematic file as well.
> > > > > > > Status:     High priority work.
> > > > > > 
> > > > > > Interesting.  This is the first time I hear of this problem.  Why did you 
> > > > > > not report it?  Do you have an example where this happens?
> > > > > 
> > > > > I identified this problem before yesterday. Sometimes I can reproduce it by
> > > > > 
> > > > > 	cp -a /usr ntfs_volume
> > > > > 	rm -rf ntfs_volume/usr
> > > > > 
> > > > > Most ntfs volumes have also such cases usually, so if you rm -rf / then you 
> > > > > can find them easily. 
> > > > 
> > > > Weird.  I wonder if it is something libntfs specific and not in the 
> > > > kernel as I have never seen this problem...
> > > 
> > > This is kernel driver problem too. It seems our knowledge about
> > > attribute list a bit incorrect. ntfs_external_attr_find written in mind
> > > with that attributes in the MFT record follow in same order as they
> > > follow in attribute list. Metadata (link to which I send in previous
> > > email) demonstrates vice-versa. FILE_NAME attributes follow in order 2,
> > > 3 (instance numbers) in the attribute list, but 3, 2 in the MFT record.
> 
> You are correct that instance numbers are in sequence in attribute list 
> attribute and are not in order in the mft record.  This is because the 
> sequence numbers are used for collation in the attribute list attribute 
> and they are not used for collation in the mft record (instead the 
> attribute value is used which in case of the file name attribute means 
> that the sequence number is irrelevant and the name is relevant instead).
> 
> What I don't understand is how that is causing file not found problems...

It caused ENOENT errno from ntfs_delete, because ntfs_delete was unable
to find requested FILE_NAME attribute during enumeration (see algorithm
if you interested in details, I think it pretty well commented).

> /me reads through ntfs_external_attr_find().
> 
> /me sees stupendously stupid bug and bashes head against wall repeatedly.
> 
> /me fixes bug and commits it to ntfsprogs.
> 
> I cannot believe this has not been found earlier!  This bug has been there 
> since I originally wrote ntfs_external_attr_find() which was quite a few 
> years ago now!  Amazing!
> 
> Yura and Szaka, thanks a lot for pointing out the problem and providing an 
> example so I could fix it!

Thanks for the fix!

-- 
Best regards,
        Yura

[Linux-NTFS-Dev] Bug#379628: ntfsresize: resizing a Vista NTFS partition leads to corrupted partition

[Frans P. <el...@pl...>]

severity 379628 important
thanks

Just tested with 1.13.1, but it turns out the problem is not in=20
ntfsresize.

The root of the problem seems to be how the Vista installer created=20
partitions. Yuval was correct: using default cylinder based partitioning,=20
the starting sector _is_ indeed changed from 2048 to 63.

Before deleting/creating the partition:
   /dev/sda1   *           1        2550    20481024    7  HPFS/NTFS
after toggling display/entry units with 'u':
   /dev/sda1   *        2048    40964095    20481024    7  HPFS/NTFS

After deleting/creating the partition:
   /dev/sda1   *           1        1217     9775521    7  HPFS/NTFS
after toggling display/entry units with 'u':
   /dev/sda1   *          63    19551104     9775521    7  HPFS/NTFS

After recreating the partition with start sector 2048, the NTFS partition=20
was correct.

I would suggest very strongly to document this aspect of resizing an NTFS=20
partition better and warn users of this possible cause of data loss.
Neither the upstream FAQ [1] nor the documentation included with the=20
package (manpage or /usr/share/doc) currently document this.
Even stronger: the example in the FAQ uses cylinders rather than sectors=20
just like I did!
The troubleshooting part of the FAQ does explain about starting sector,=20
but does not explain the difference between cylinders based and sector=20
based partitioning. Most users will react the same as I did: "but the=20
start is still at 1, so that cannot be the problem".

Reducing the severity of this bug report to from RC to important as I feel=
=20
properly documenting this deserves that severity.

With this information, I will try to see if we can fix this issue in the=20
Debian Installer. Thank you for helping find the cause of the issue.

Cheers,
=46JP

[1] http://mlf.linux.rulez.org/mlf/ezaz/ntfsresize.html

[Linux-NTFS-Dev] Problem autobuilding ntfsprogs on alpha.

[David <en...@de...>]

	Hello, developers.  I have noticed problems building linux-ntfs on Alpha=20
architecture:

gcc -DHAVE_CONFIG_H -I. -I. -I.. -I../include/ntfs -DLTVERSION_LIBNTFS=3D\"=
9:0:0\" -Wall -g -O2 -Wall -MT=20
libntfs_la-logging.lo -MD -MP -MF .deps/libntfs_la-logging.Tpo -c=20
logging.c  -fPIC -DPIC -o .libs/libntfs_la-logging.o
logging.c: In function 'ntfs_log_handler_syslog':
logging.c:365: error: incompatible types in assignment
logging.c: In function 'ntfs_log_handler_fprintf':
logging.c:450: error: incompatible types in assignment
make[3]: *** [libntfs_la-logging.lo] Error 1
make[3]: Leaving directory `/build/buildd/linux-ntfs-1.13.1/libntfs'

	Full build log follows:

http://buildd.debian.org/fetch.php?&pkg=3Dlinux-ntfs&ver=3D1.13.1-2&arch=3D=
alpha&stamp=3D1153789838&file=3Dlog&as=3Draw

	Thanks in advance,


		Ender.
=2D-=20
=2D Kyle, all those times I said you were a dumb, stupid Jew,
  well, I was wrong, you're not a Jew.
=2D Cartman, I *am* Jewish!
=2D There, there, don't be hard on yourself, Kyle.
		-- Cartman & Kyle (South Park).
=2D-
Desarrollador de Debian
Debian developer

Re: [Linux-NTFS-Dev] [Linux-NTFS Forum: Usage Problems] RE: Large files - slow

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

On Tue, 25 Jul 2006, Yuval Fledel wrote:
> [Moving a discussion that started on the forum to the mailing list.
> Both because the discussion is now more technical, and because I
> attached a file]
> 
> On 7/24/06, AntonA wrote:
> > I mean yes, the runlist lookups are pretty inneficient but they are not
> > _that_ inefficient and it should not cause such slowdown.  Same for the
> > allocator it should not make a difference like this...
> 
> After profiling ntfs-3g-20070714, the problem is actually building the
> runlist (profiling output attached).
> 
> Anyone interested in picking up the glove?
> 
> > For comparison using the kernel ntfs driver (Linux) and doing just a dd
> > like so:
> > 
> > date && time dd if=/dev/zero of=test-big-file count=1 bs=1G && date
> > 
> > Gives me:
> > 
> > Mon Jul 24 19:49:58 BST 2006
> > 1+0 records in
> > 1+0 records out
> > 1073741824 bytes (1.1 GB) copied, 27.2384 seconds, 39.4 MB/s
> > 
> > real    0m27.242s
> > user    0m0.000s
> > sys     0m7.460s
> > Mon Jul 24 19:50:25 BST 2006
> > 
> > So it took only 27 seconds...
> 
> Unless the kernel driver is not creating sparse files, this is not a
> good comparison. ntfs-3g on my laptop did the same micro-benchmark in
> 66 seconds. The output file was indeed 1GB, but took on disk 0 bytes
> (not counting metadata).

The kernel driver does not create sparse files at all.  66 seconds to 
create a sparse file?  Ouch.  And how did it know to create a sparse file?  
I hope it is not scanning all incoming data for zeroes?  That would slow 
it down like hell.  No other file system does that...  The only way sparse 
regions are created by doing "lseek(past end of file)+write()".

> For comparison, coping a large file from one ntfs partition mounted
> using the kernel driver to another ntfs partition mounted using
> ntfs-3g copied ~142MB in 5:19 minutes. (actual size on disk: 134MB):
> real    5m18.255s
> user    0m0.028s
> sys     0m0.728s

And how about with the kernel driver as destination?  (Just do "touch 
destination" mounting with ntfs-3g, then unmount, mount with kernel driver 
and do the copy.)

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, http://www.linux-ntfs.org/

Re: [Linux-NTFS-Dev] Bug#379628: ntfsresize: resizing a Vista NTFS partition leads to corrupted partition

[Frans P. <el...@pl...>]

On Tuesday 25 July 2006 01:25, Yuval Fledel wrote:
> 20482843+ is different than 20481024. I know for sure that when I
> repartitioned my disk, and entered the same number, only that it
> showed with no +, Windows no longer agreed to boot. Returning the
> partition table to what it was saved the day.

Well, these were in both cases (and certainly the Vista case) partitions=20
created by the Windows installer itself, and Windows certainly booted=20
before resizing. So to me it seems irrelevant for this issue.

Re: [Linux-NTFS-Dev] Bug#379628: ntfsresize: resizing a Vista NTFS partition leads to corrupted partition

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

On 7/24/06, Frans Pop <el...@pl...> wrote:
> Thanks for your quick reaction Yuval.
>
> On Monday 24 July 2006 19:42, Yuval Fledel wrote:
> > > The two are completely similar, except that the first is successful
> > > and the second leads to corruption.
> >
> > I noticed that the original partition was not the same in both cases.
> > example:
> > Vista: /dev/sda1   *           1        1217     9775521    7
> > HPFS/NTFS
> > 2000:  /dev/sda1   *           1        2550    20482843+   7
> > HPFS/NTFS
>
> No that is not correct (Vista will not even install into less than 16
> MB :-)

Sorry, I copied the wrong line for Vista.
/dev/sda1   *           1        2550    20481024    7  HPFS/NTFS

20482843+ is different than 20481024. I know for sure that when I
repartitioned my disk, and entered the same number, only that it
showed with no +, Windows no longer agreed to boot. Returning the
partition table to what it was saved the day.

> It also feels strange because I did not change the starting sector and the
> end sector was well bigger than the new size of the NTFS partition.

When you work with a "cluster" unit, fdisk sometimes move the starting
sector. This is because a cluster may contain several sectors, and the
original starting sector may not be cluster-aligned. When the first
sector moves, the tools and the kernel driver can no longer mount the
partition.

> Ah, I see 1.13.1 has just hit unstable. I will test with that and let you
> know.

Thanks, that would be helpful.

-- 
Yuval Fledel

Re: [Linux-NTFS-Dev] [Linux-NTFS Forum: Usage Problems] RE: Large files - slow

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

[Moving a discussion that started on the forum to the mailing list.
Both because the discussion is now more technical, and because I
attached a file]

On 7/24/06, AntonA wrote:
> I mean yes, the runlist lookups are pretty inneficient but they are not
> _that_ inefficient and it should not cause such slowdown.  Same for the
> allocator it should not make a difference like this...

After profiling ntfs-3g-20070714, the problem is actually building the
runlist (profiling output attached).

Anyone interested in picking up the glove?

> For comparison using the kernel ntfs driver (Linux) and doing just a dd
> like so:
>
> date && time dd if=/dev/zero of=test-big-file count=1 bs=1G && date
>
> Gives me:
>
> Mon Jul 24 19:49:58 BST 2006
> 1+0 records in
> 1+0 records out
> 1073741824 bytes (1.1 GB) copied, 27.2384 seconds, 39.4 MB/s
>
> real    0m27.242s
> user    0m0.000s
> sys     0m7.460s
> Mon Jul 24 19:50:25 BST 2006
>
> So it took only 27 seconds...

Unless the kernel driver is not creating sparse files, this is not a
good comparison. ntfs-3g on my laptop did the same micro-benchmark in
66 seconds. The output file was indeed 1GB, but took on disk 0 bytes
(not counting metadata).

For comparison, coping a large file from one ntfs partition mounted
using the kernel driver to another ntfs partition mounted using
ntfs-3g copied ~142MB in 5:19 minutes. (actual size on disk: 134MB):
real    5m18.255s
user    0m0.028s
sys     0m0.728s

-- 
Yuval Fledel

Re: [Linux-NTFS-Dev] ntfsresize: resizing a Vista NTFS partition leads to corrupted partition

[Frans P. <el...@pl...>]

Thanks for your quick reaction Yuval.

On Monday 24 July 2006 19:42, Yuval Fledel wrote:
> > The two are completely similar, except that the first is successful
> > and the second leads to corruption.
>
> I noticed that the original partition was not the same in both cases.
> example:
> Vista: /dev/sda1   *           1        1217     9775521    7 =20
> HPFS/NTFS
> 2000:  /dev/sda1   *           1        2550    20482843+   7=20
> HPFS/NTFS

No that is not correct (Vista will not even install into less than 16=20
MB :-)

=46rom the log:
Current volume size: 20972564992 bytes (20973 MB)
Current device size: 20972568576 bytes (20973 MB)

/dev/sda1   *           1        2550    20481024    7  HPFS/NTFS

That is the same in both cases.

> > The corruption only becomes clear _after_ the physical partition is
> > resized too; resizing the partition back to its original size does
> > not get the partition back. ntfsfix does not help either.
> > Note that during the manual resize operation I used fdisk, but the
> > installer uses libparted; the corruption occurs with both.
>
> If the partition was mountable before changing the physical partition,
> it is most likely that the bug is in the partitionning tool, and not
> in ntfsresize.
>
> I know that Szaka (ntfsresize's author) tested ntfsresize on Windows
> Vista's partitions, and it worked. He is in vocation at the moment and
> can not reply.
>
> Can you check the partitioning again, and this time with sectors as
> unit like ntfsresize states (use the "u" command in fdisk). This one
> is the most common cause for the problem at hand.

Hmm. I did not note anything about that in the FAQ (happy to be proven=20
wrong), and it still feels like a regression because with NTFS 1.2 my=20
method did work correctly. However, I will give it a try.

It also feels strange because I did not change the starting sector and the=
=20
end sector was well bigger than the new size of the NTFS partition.

Also note that it means that 2 major linux partitioning tools (fdisk and=20
parted) would be wrong.

> It is always good to check with the latest version. I'd appriciate if
> you check with 1.13.1 instead of an older version.

Ah, I see 1.13.1 has just hit unstable. I will test with that and let you=20
know.

[Linux-NTFS-Dev] ntfsresize: resizing a Vista NTFS partition leads to corrupted partition

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

I'm forwarding Debian Bug#379628 with its attachments: ntfsresize:
resizing a Vista NTFS partition leads to corrupted partition.
The bug can be viewed online in
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=379628

On 7/24/06, Frans Pop wrote:
> Package: ntfsprogs
> Version: 1.12.1-1
> Severity: critical
> Justification: causes serious data loss
> Tags: d-i
>
> After a resize using Debian Installer of an NTFS partition created with
> Windows Vista Beta 2, I found that the partition was no longer usable.
>
> I have checked that this really is an issue by doing manual resizes of:
> - an NTFS (1.2) partition created by installing Windows 2000
> - an NTFS (3.1) partition created by installing Windows Vista Beta 2
>
> The two are completely similar, except that the first is successful and
> the second leads to corruption.

I noticed that the original partition was not the same in both cases. example:
Vista: /dev/sda1   *           1        1217     9775521    7  HPFS/NTFS
2000:  /dev/sda1   *           1        2550    20482843+   7  HPFS/NTFS

> The corruption only becomes clear _after_ the physical partition is
> resized too; resizing the partition back to its original size does not
> get the partition back. ntfsfix does not help either.
> Note that during the manual resize operation I used fdisk, but the
> installer uses libparted; the corruption occurs with both.

If the partition was mountable before changing the physical partition,
it is most likely that the bug is in the partitionning tool, and not
in ntfsresize.

I know that Szaka (ntfsresize's author) tested ntfsresize on Windows
Vista's partitions, and it worked. He is in vocation at the moment and
can not reply.

Can you check the partitioning again, and this time with sectors as
unit like ntfsresize states (use the "u" command in fdisk). This one
is the most common cause for the problem at hand.

> Logs for the resize of both NTFS partitions are attached and clearly show
> the problem.
>
> I noticed that a 1.13.1 release is available, but cannot tell from the
> changelog if that would fix this issue.

It is always good to check with the latest version. I'd appriciate if
you check with 1.13.1 instead of an older version.

> -- System Information:
> Debian Release: testing/unstable
>   APT prefers unstable
>   APT policy: (500, 'unstable')
> Architecture: amd64 (x86_64)
> Shell:  /bin/sh linked to /bin/bash
> Kernel: Linux 2.6.15-1-amd64-generic
> Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8)
>
> Versions of packages ntfsprogs depends on:
> ii  libc6               2.3.6-15   GNU C Library: Shared libraries
> ii  libfuse2            2.5.3-2.1  Filesystem in USErspace library
> ii  libntfs8            1.12.1-1   library that provides common NTFS
>
> ntfsprogs recommends no packages.
>
> -- no debconf information

Also, please don't use ntfsfix in this scenario. It was not meant for that.

-- 
Yuval Fledel

Re: [Linux-NTFS-Dev] [announcement] ntfs-3g: open source read-write driver

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

On Sun, 23 Jul 2006, Yura Pakhuchiy wrote:
> On Sun, 23 Jul 2006 at 08:33 +0300, Yura Pakhuchiy wrote:
> > On Sat, 15 Jul 2006 at 20:46 +0100, Anton Altaparmakov wrote:
> > > > > > Problem:    "No such file or directory" message when accessing some files:
> > > > > > Answer:     This is a known problem in libntfs inode attribute enumeration 
> > > > > >             when the same type of attributes are distributed across
> > > > > >             multiply mft records. Occures only very rarely.
> > > > > > Workaround: If the file is a hard link (usually yes) then first delete
> > > > > >             some other files hard linking to the same file then you'll
> > > > > >             be able to delete the problematic file as well.
> > > > > > Status:     High priority work.
> > > > > 
> > > > > Interesting.  This is the first time I hear of this problem.  Why did you 
> > > > > not report it?  Do you have an example where this happens?
> > > > 
> > > > I identified this problem before yesterday. Sometimes I can reproduce it by
> > > > 
> > > > 	cp -a /usr ntfs_volume
> > > > 	rm -rf ntfs_volume/usr
> > > > 
> > > > Most ntfs volumes have also such cases usually, so if you rm -rf / then you 
> > > > can find them easily. 
> > > 
> > > Weird.  I wonder if it is something libntfs specific and not in the 
> > > kernel as I have never seen this problem...
> > 
> > This is kernel driver problem too. It seems our knowledge about
> > attribute list a bit incorrect. ntfs_external_attr_find written in mind
> > with that attributes in the MFT record follow in same order as they
> > follow in attribute list. Metadata (link to which I send in previous
> > email) demonstrates vice-versa. FILE_NAME attributes follow in order 2,
> > 3 (instance numbers) in the attribute list, but 3, 2 in the MFT record.

You are correct that instance numbers are in sequence in attribute list 
attribute and are not in order in the mft record.  This is because the 
sequence numbers are used for collation in the attribute list attribute 
and they are not used for collation in the mft record (instead the 
attribute value is used which in case of the file name attribute means 
that the sequence number is irrelevant and the name is relevant instead).

What I don't understand is how that is causing file not found problems...

/me reads through ntfs_external_attr_find().

/me sees stupendously stupid bug and bashes head against wall repeatedly.

/me fixes bug and commits it to ntfsprogs.

I cannot believe this has not been found earlier!  This bug has been there 
since I originally wrote ntfs_external_attr_find() which was quite a few 
years ago now!  Amazing!

Yura and Szaka, thanks a lot for pointing out the problem and providing an 
example so I could fix it!

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, http://www.linux-ntfs.org/