Szakacsits Szabolcs wrote:
> For full information and decoding see the output of
>
> ntfsinfo -vi <inode> <volume>
>
> which will also find the "missing" $INDEX_ALLOCATION ;-)
You're right, it does. Yet when I print out the hex dump of the whole
MFT record, it isn't in there. So I guess it's being pointed to by the
$ATTRIBUTE_LIST attribute, which is allegedly rare but indeed present in
this case. In other words, my misunderstanding was probably just
elsewhere. :-)
Daniel
--
Daniel Noll
Nuix Pty Ltd
Suite 79, 89 Jones St, Ultimo NSW 2007, Australia Ph: +61 2 9280 0699
Web: http://www.nuix.com.au/ Fax: +61 2 9212 6902
This message is intended only for the named recipient. If you are not
the intended recipient you are notified that disclosing, copying,
distributing or taking any action in reliance on the contents of this
message or attachment is strictly prohibited.

Hi,
On Fri, 2006-06-23 at 13:58 +0900, prakash viswalingam wrote:
> Hi All,
> This is my first post to this community, hoping to get a good solution.
>
> I am trying to read the ntfs files from DOS , I am reading the files
> which has data attribute but some file doesn't have data attribute
> ,instead it has Attribute List Attribute .In my case I am trying to
> decode the List Attribute ,here it is a resident attribute and i am
> getting the type of reference attribute is 0x10 (ie., Standard
> attribute )
> and size is 32 bytes ,
> but my LCN and attribute ID (instance ) is also zero .
>
> so somebody pls suggest me how to read the data attribute of this
> particular file ?or
> How to decode this Attribute List to get the Data Attribute or Data
> information .
>
> I also given the information of Attribute List which has generated
> from my system.
>
> Type=0x10
> Size =32
> Name Lenght=0x00
> OffsetName =0x1A;
> starting VCN =0x00;
> Base File Reference =0x000600000000030C
> Attribute ID =0x00
This is only the first attribute list attribute record. Keep reading
records until you find the one for the data attribute... See
ntfsprogs/include/ntfs/layout.h (search for ATTR_LIST_ENTRY) for
details...
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/

Hi All,
This is my first post to this community, hoping to get a good solution.
I am trying to read the ntfs files from DOS , I am reading the files
which has data attribute but some file doesn't have data attribute
,instead it has Attribute List Attribute .In my case I am trying to
decode the List Attribute ,here it is a resident attribute and i am
getting the type of reference attribute is 0x10 (ie., Standard
attribute )
and size is 32 bytes ,
but my LCN and attribute ID (instance ) is also zero .
so somebody pls suggest me how to read the data attribute of this
particular file ?or
How to decode this Attribute List to get the Data Attribute or Data
information .
I also given the information of Attribute List which has generated
from my system.
Type=0x10
Size =32
Name Lenght=0x00
OffsetName =0x1A;
starting VCN =0x00;
Base File Reference =0x000600000000030C
Attribute ID =0x00
Thanks in advance
Thanks and regards
V.Prakash

Hi,
I am the LinuxConsole developer. Thanks to your ntfs driver, windows
users can start my distro without changing their disk partitions
(http://linuxconsole.org/wiki/doku.php?id=3Dman:installwin10).
I noticed a bug since kernel 2.6.15.1 (I made some tests on 5
computeurs, but there is only one that is wrong) : when the systems
mount the ntfs partitions, the mount process becomes in "uninterruptible
sleep" state.
This fails whith kernels 2.6.15.1 and 2.6.17.1, but it is OK with
2.6.14.3.
Could you give me the way to debug this ?
Regards.
Yann Le Doar=E9.
Note : I done a "chkdsk /F" from XP, and the filesystem have no errors.

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Hi,
Anton Altaparmakov wrote:
> On Wed, 2006-06-21 at 13:15 +0200, Szakacsits Szabolcs wrote:
>> On Wed, 21 Jun 2006, Mario Emmenlauer wrote:
>>
>>> But then why keep the cms at all? All the content we have could go
>>> into the wiki too, and we wouldn't have to maintain three systems but
>>> only two.
>> I wasn't aware it does nothing else. So yes, then we could forget about
>> CMS entirely.
It does the news and the downloads. Also AFAIK Rich is doing some
work for his rpm-management using Joomla.
But all of my scripts can be adopted to use the wiki, and I guess
Rich's work could be made a stand-alone project that would export to
dokuwiki?! Rich?
Editing the wiki is just so much simpler that I would go for
the wiki, (almost) no matter what cost.
> I agree. The only thing is the scripts that do the news and downloads.
> The news are easy enough, I just need to copy and paste when posting the
> news on Sf.net into the wiki. Not a problem at all.
That would be a 20-liner in bash, so no big deal to write.
Having my old script makes it even more easy.
> And the script
> does not seem to work that well anyway. (It now has lost the 1.13.0
> release completely and still has 1.11.2 twice...)
:-) I can fix that in mysql directly, don't mind.
> The dowloads script is rather nice to have. Perhaps it could be
> scripted so I just need to log in to linux-ntfs.org and run it manually
> and it would edit the wiki? I suppose it would not be too bad to do it
> by hand. I would just have to edit the existing one and change the
> version number everywhere, so yes, no problem.
Same as above, I'll write a cronjob in bash for that too.
> If it really is not doing anything else, then yes, lets make
> http://www.linux-ntfs.org the wiki and be done with it. (-:
>
> ps. Mario, obviously feel free to wait until you are less busy...
Jup, we'll have to wait until then :-(
Cheers,
Mario
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.3 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
iD8DBQFEmS8WzxGsM4+WvrURAum3AJwPDTz8j1SVcXdbdSbzkRuKmvRMZgCggUby
r7tkQFz4kD8F0rir7DofMwQ=
=1+5m
-----END PGP SIGNATURE-----

On Wed, 2006-06-21 at 13:15 +0200, Szakacsits Szabolcs wrote:
> On Wed, 21 Jun 2006, Mario Emmenlauer wrote:
>
> > But then why keep the cms at all? All the content we have could go
> > into the wiki too, and we wouldn't have to maintain three systems but
> > only two.
>
> I wasn't aware it does nothing else. So yes, then we could forget about
> CMS entirely.
I agree. The only thing is the scripts that do the news and downloads.
The news are easy enough, I just need to copy and paste when posting the
news on Sf.net into the wiki. Not a problem at all. And the script
does not seem to work that well anyway. (It now has lost the 1.13.0
release completely and still has 1.11.2 twice...)
The dowloads script is rather nice to have. Perhaps it could be
scripted so I just need to log in to linux-ntfs.org and run it manually
and it would edit the wiki? I suppose it would not be too bad to do it
by hand. I would just have to edit the existing one and change the
version number everywhere, so yes, no problem.
If it really is not doing anything else, then yes, lets make
http://www.linux-ntfs.org the wiki and be done with it. (-:
ps. Mario, obviously feel free to wait until you are less busy...
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/

On Wed, 21 Jun 2006, Mario Emmenlauer wrote:
> But then why keep the cms at all? All the content we have could go
> into the wiki too, and we wouldn't have to maintain three systems but
> only two.
I wasn't aware it does nothing else. So yes, then we could forget about
CMS entirely.
Szaka

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Hi,
sort-of on topic:
I'm sad to say that for the next 10 weeks I'm busy as hell -
I'll just have to study a lot.
I will still be available for smaller updates: next is the forum-
update to 2.0.21 and then I'll add elwins slightly improved website-
images to the layout (he was so kind to look over *all* the colorings
so the different shades of blue match better).
Other than that I'll only do bugfixes until beginning of October,
but I still urge you to bug me if any errors occur!
- From Oktober on I'll have more free time, so I might do all the
cvs-to-wiki transfers and maybe even re-write the FAQ with all the
latest updates.
Cheers,
Mario
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.3 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
iD8DBQFEmSdlzxGsM4+WvrURAn4yAJ4yhAa9VdGUL23+dISdOn56erBpXACfeb4q
WgitrM6f5TL0tkm+SmO4HUg=
=OZGR
-----END PGP SIGNATURE-----

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Hi,
Anton Altaparmakov wrote:
> On Wed, 2006-06-21 at 12:27 +0200, Szakacsits Szabolcs wrote:
>> On Wed, 21 Jun 2006, Anton Altaparmakov wrote:
>>
>>> Could someone please update:
>>>
>>> - Freshmeat with the new release.
>> Done.
>
> Great, thanks!
>
>>> - linux-ntfs.org with the news (tried to do it myself but didn't seem to
>>> do anythign at all).
>>>
>>> - linux-ntfs.org title page with the new release (don't know how to edit
>>> the main page).
>> BTW, didn't we agree that wiki will replace the editable part of the CMS?
>> If not yet, then I think we should.
>
> Did we? I can't remember but I am all for it. The CMS is horrifyingly
> complicated. At least I don't understand it at all... I only had a few
> goes at it admittedly but I always got completely lost in it...
We had discussed it, but without any real conclusion - mainly because
the wiki had no menu back then.
Anyways, times have changed, and I'm all for it too. But then why keep
the cms at all? All the content we have could go into the wiki too, and
we wouldn't have to maintain three systems but only two.
Cheers,
Mario
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.3 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
iD8DBQFEmSUkzxGsM4+WvrURApJvAJoCeBddFiPZg25Y19UGVBVsTUylwwCeKVfL
UT7PRblmyT8mS7fAh1pk7LQ=
=lWGl
-----END PGP SIGNATURE-----

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Hi,
damn, you all mail too fast, can't keep up with my replies...
Anton Altaparmakov wrote:
> On Wed, 2006-06-21 at 11:46 +0100, Anton Altaparmakov wrote:
>> On Wed, 2006-06-21 at 11:42 +0100, Chris Brown wrote:
>>> On Wed, 21 Jun 2006, Anton Altaparmakov wrote:
>>> > Could someone please update:
>>>
>>> > - linux-ntfs.org with the news (tried to do it myself but
>>> didn't seem to
>>> > do anythign at all).
>>> >
>>>
>>> Done.
>> Does not seem to have worked. It now lists the 1.13.0 release twice.
>
> Weird it now shows 1.13.1 but only after 1.13.0 so it got the order
> wrong. And 1.11.2 is there twice as well...
Could it be that nobody updated to 1.13.0? If it finds several updates
at once it might re-order them.
I can fix that asap...
Cheers,
Mario
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.3 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
iD8DBQFEmSSYzxGsM4+WvrURAtMSAJ0T+m0BrvEfa+3Hs9z63Fif9ooODACbBFS3
TV2WbxA69Z5+SwSU0fvZIMg=
=mYH9
-----END PGP SIGNATURE-----

Hi,
On Wed, 2006-06-21 at 12:27 +0200, Szakacsits Szabolcs wrote:
> On Wed, 21 Jun 2006, Anton Altaparmakov wrote:
>
> > Could someone please update:
> >
> > - Freshmeat with the new release.
>
> Done.
Great, thanks!
> > - linux-ntfs.org with the news (tried to do it myself but didn't seem to
> > do anythign at all).
> >
> > - linux-ntfs.org title page with the new release (don't know how to edit
> > the main page).
>
> BTW, didn't we agree that wiki will replace the editable part of the CMS?
> If not yet, then I think we should.
Did we? I can't remember but I am all for it. The CMS is horrifyingly
complicated. At least I don't understand it at all... I only had a few
goes at it admittedly but I always got completely lost in 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 / IRC: #ntfs on irc.freenode.net
WWW: http://linux-ntfs.sf.net/ & http://www-stu.christs.cam.ac.uk/~aia21/

>
>
> On Wed, 21 Jun 2006, Anton Altaparmakov wrote:
>
> > Could someone please update:
>
> > - linux-ntfs.org with the news (tried to do it myself but didn't seem to
> > do anythign at all).
> >
Done.
> - linux-ntfs.org title page with the new release (don't know how to edit
> > the main page).
Done.
BTW, didn't we agree that wiki will replace the editable part of the CMS?
> If not yet, then I think we should.
>
I agree, for clarity. I have to say that I think we need (better)
clarification on ntfsmount vs kernel driver.
Cheers
Chris

Hi,
On Wed, 21 Jun 2006, Anton Altaparmakov wrote:
> Could someone please update:
>
> - Freshmeat with the new release.
Done.
> - linux-ntfs.org with the news (tried to do it myself but didn't seem to
> do anythign at all).
>
> - linux-ntfs.org title page with the new release (don't know how to edit
> the main page).
BTW, didn't we agree that wiki will replace the editable part of the CMS?
If not yet, then I think we should.
Szaka

Hi all,
Congratulations all on our long overdue release (sorry about taking so
long to do it)!
Could someone please update:
- Freshmeat with the new release.
- linux-ntfs.org with the news (tried to do it myself but didn't seem to
do anythign at all).
- linux-ntfs.org title page with the new release (don't know how to edit
the main page).
Thanks,
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/

Lots of fixes across the board. Update is strongly recommended. See
the changelog for details.
You can download rpms and source code of the 1.13.1 release:
http://www.linux-ntfs.org/content/view/19/37/
Or get the changes from the Linux-NTFS CVS, for details see:
http://www.linux-ntfs.org/content/view/18/36/
ChangeLog since 1.13.0 release:
- Fix bug in ntfs_attr_pwrite() when we sometimes lose current run in
the runlist. (Yura)
- Fix build with --disable-gnome-vfs --enable-fuse-module. (Gentoo)
- ntfscluster: identify files even if their clusters aren't set
in $Bitmap (useful to find potentially corrupted files). (Szaka)
- mkntfs: set the physical drive and the extended boot signature to
0x80 in the Extended BPB which are needed to boot from disk. (Szaka)
- ntfsinfo: fix two freed memory usages when dumping $SDS and index
allocation entries. (Szaka)
- libntfs: add ntfs_attr_readall() which reads the entire data
from an ntfs attribute. (Szaka)
- libntfs: add ntfs_index_root_get() which reads the index root of
an attribute. (Szaka)
- ntfsclone: the --metadata option will wipe the timestamps in the
index allocation attributes as well. This further decreases the
compressed metadata image size by 10-25% and more importantly it
eliminates non-interesting ntfscmp differences. (Szaka)
- Change utils_parse_size() to use a base of 0 instead of 10 when
calling strtoll(). This automagically allows specification of
numbers in hex (and octal if anyone is crazy enough to use that) in
addition to decimal numbers on the command line options to most if
not all utilities. (Anton)
- Fix comparison of $MFT and $MFTMirr to not bail out when there are
unused, invalid mft records which are the same in both $MFT and
$MFTMirr. Ported from kernel driver 2.1.27 release and aplied both
to libntfs/volume.c mount related code and to ntfsprogs/ntfsfix.c's
fixup code. (Anton)
- Change ntfsinfo to dump the key data as well as the keys themselves
when dumping the $ObjId/$O index. (Anton)
- ntfsinfo: dump either a minimal (default) or the entire attribute
header (--verbose) for all attribute types. Dump USA, USN and LSN
for index records. Removed a lot of redundant code, made some
formatting and stylistic corrections. (Szaka)
- libntfs: add ntfs_str2ucs(), ntfs_freeucs(), ntfs_mft_usn_dec()
and ntfs_inode_badclus_bad() functions, and convert all copy-pastes
to use them. (Szaka)
- Fix all incorrect getopt_long() return value usages. (Szaka)
- Fix VCN size in the index.c. (Anton, Yura)
- ntfscmp: support bad cluster list, compare full attribute headers
for non-resident attributes, added manual, build and install by
default. (Szaka)
- configure.ac: set PKG_CONFIG_PATH during build time so we should
find .pc files in the most typical pkgconfig directories. (Szaka)
- Improve ntfsinfo to dump standard info completely and filename
attribute completely and index entry (filename) completely and all in
correct order. Essential for hunting bugs in directory operations
code... (Anton)
- configure.ac fix for Cygwin. (Yuval)
- Fix bug with renaming directories with names in DOS and WIN32
namespaces. (Yura)
- ntfsclone: fix 64 bit destination size calculation on Mac OS X
(Mike Bombich, Anton, Szaka)
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/

Hi Linus/Andrew,
Please apply the below patch. It fixes a crash in NTFS on architectures
where flush_dcache_page() is a real function. I never noticed this as all
my testing is done on i386 where flush_dcache_page() is NULL.
Many thanks to Pauline Ng for the detailed bug report and analysis!
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/
---
[NTFS] Fix critical bug in ntfs_flush_dcache_pages().
Many thanks to Pauline Ng for the detailed bug report and analysis!
Signed-off-by: Anton Altaparmakov <aia21@...>
diff --git a/fs/ntfs/file.c b/fs/ntfs/file.c
index c63a83e..36e1e13 100644
--- a/fs/ntfs/file.c
+++ b/fs/ntfs/file.c
@@ -1484,14 +1484,15 @@ static inline void ntfs_flush_dcache_pag
unsigned nr_pages)
{
BUG_ON(!nr_pages);
+ /*
+ * Warning: Do not do the decrement at the same time as the call to
+ * flush_dcache_page() because it is a NULL macro on i386 and hence the
+ * decrement never happens so the loop never terminates.
+ */
do {
- /*
- * Warning: Do not do the decrement at the same time as the
- * call because flush_dcache_page() is a NULL macro on i386
- * and hence the decrement never happens.
- */
+ --nr_pages;
flush_dcache_page(pages[nr_pages]);
- } while (--nr_pages > 0);
+ } while (nr_pages > 0);
}
/**