|
From: ? <sz...@us...> - 2002-07-09 09:07:14
|
Changes by: szaka
Update of /cvsroot/linux-ntfs/linux-ntfs/ntfstools
In directory usw-pr-cvs1:/tmp/cvs-serv31866
Modified Files:
ntfsresize.c
Log Message:
Don't give up inode walking on EIO: temporary fix for not being
able to distinguish corrupt and not FILE records easily)
Index: ntfsresize.c
===================================================================
RCS file: /cvsroot/linux-ntfs/linux-ntfs/ntfstools/ntfsresize.c,v
retrieving revision 1.3
retrieving revision 1.4
diff -U2 -r1.3 -r1.4
--- ntfsresize.c 9 Jul 2002 00:00:19 -0000 1.3
+++ ntfsresize.c 9 Jul 2002 09:07:10 -0000 1.4
@@ -2,5 +2,5 @@
* ntfsresize - Part of the Linux-NTFS project.
*
- * Copyright (c) 2002 Szakacsits Szabolcs
+ * Copyright (c) 2002 Szabolcs Szakacsits
*
* This utility will resize an NTFS volume.
@@ -65,6 +65,6 @@
-int err_exit(const char *fmt, ...) {
-
+int err_exit(const char *fmt, ...)
+{
va_list ap;
@@ -79,6 +79,6 @@
-void usage(char *s) {
-
+void usage(char *s)
+{
printf ("Usage: %s [-nv] [-c clusters] device\n", s);
printf (" -c clusters New NTFS size in clusters\n");
@@ -90,6 +90,6 @@
-void parse_options(int argc, char **argv) {
-
+void parse_options(int argc, char **argv)
+{
char *s;
int i;
@@ -130,6 +130,6 @@
-s64 nr_clusters_to_bitmap_byte_size(s64 nr_clusters) {
-
+s64 nr_clusters_to_bitmap_byte_size(s64 nr_clusters)
+{
s64 bm_bsize;
@@ -145,6 +145,6 @@
-void build_lcn_usage_bitmap(ATTR_RECORD *a) {
-
+void build_lcn_usage_bitmap(ATTR_RECORD *a)
+{
run_list *rl;
int i, j;
@@ -170,6 +170,6 @@
-void walk_attributes(MFT_RECORD *mr) {
-
+void walk_attributes(MFT_RECORD *mr)
+{
ntfs_attr_search_ctx *ctx;
@@ -187,6 +187,6 @@
-void get_bitmap_data(ntfs_volume *vol, struct bitmap *bm) {
-
+void get_bitmap_data(ntfs_volume *vol, struct bitmap *bm)
+{
ntfs_inode *ni;
ntfs_attr_search_ctx *ctx;
@@ -214,6 +214,6 @@
-void compare_bitmaps(struct bitmap *a, struct bitmap *b) {
-
+void compare_bitmaps(struct bitmap *a, struct bitmap *b)
+{
int i;
@@ -229,6 +229,6 @@
-void walk_inodes() {
-
+void walk_inodes()
+{
s32 inode;
MFT_REF mref;
@@ -237,6 +237,9 @@
for (inode = 0; inode < vol->nr_mft_records; inode++) {
mref = (MFT_REF)inode;
- if (ntfs_read_file_record(vol, mref, &mrec, NULL))
- perr_exit("ntfs_read_file_record");
+ if (ntfs_read_file_record(vol, mref, &mrec, NULL)) {
+ if (errno == EIO)
+ continue;
+ perr_exit("ntfs_read_file_record");
+ }
if (!(mrec->flags & MFT_RECORD_IN_USE))
continue;
@@ -249,6 +252,6 @@
-void advise_on_resize() {
-
+void advise_on_resize()
+{
u64 i;
@@ -266,6 +269,6 @@
-void look_for_bad_sector(ATTR_RECORD *a) {
-
+void look_for_bad_sector(ATTR_RECORD *a)
+{
run_list *rl;
int i;
@@ -283,6 +286,6 @@
-void rl_set(run_list *rl, VCN vcn, LCN lcn, s64 len) {
-
+void rl_set(run_list *rl, VCN vcn, LCN lcn, s64 len)
+{
rl->vcn = vcn;
rl->lcn = lcn;
@@ -295,6 +298,6 @@
* must be set. This region also encompasses the backup boot sector.
*/
-void bitmap_file_data_fixup(s64 clusters, struct bitmap *bm) {
-
+void bitmap_file_data_fixup(s64 clusters, struct bitmap *bm)
+{
s64 i;
@@ -308,6 +311,6 @@
* "truncate_bitmap_unnamed_attr()"
*/
-void truncate_badclust_bad_attr(ATTR_RECORD *a, s64 nr_clusters) {
-
+void truncate_badclust_bad_attr(ATTR_RECORD *a, s64 nr_clusters)
+{
run_list *rl_bad;
int mp_size;
@@ -342,6 +345,6 @@
-void truncate_bitmap_unnamed_attr(ATTR_RECORD *a, s64 nr_clusters) {
-
+void truncate_bitmap_unnamed_attr(ATTR_RECORD *a, s64 nr_clusters)
+{
run_list *rl;
s64 bm_bsize, size;
@@ -423,6 +426,6 @@
-void lookup_data_attr(MFT_REF mref, char *aname, ntfs_attr_search_ctx **ctx) {
-
+void lookup_data_attr(MFT_REF mref, char *aname, ntfs_attr_search_ctx **ctx)
+{
ntfs_inode *ni;
uchar_t *ustr = NULL;
@@ -451,6 +454,6 @@
-int write_mft_record(ntfs_attr_search_ctx *ctx) {
-
+int write_mft_record(ntfs_attr_search_ctx *ctx)
+{
if (opt.ro_flag)
return 0;
@@ -460,6 +463,6 @@
-void truncate_badclust_file(s64 nr_clusters) {
-
+void truncate_badclust_file(s64 nr_clusters)
+{
ntfs_attr_search_ctx *ctx = NULL;
@@ -478,6 +481,6 @@
-void truncate_bitmap_file(s64 nr_clusters) {
-
+void truncate_bitmap_file(s64 nr_clusters)
+{
ntfs_attr_search_ctx *ctx = NULL;
@@ -493,6 +496,6 @@
-void setup_lcn_bitmap() {
-
+void setup_lcn_bitmap()
+{
/* Determine lcn bitmap byte size and allocate it. */
lcn_bitmap.size = nr_clusters_to_bitmap_byte_size(vol->nr_clusters);
@@ -506,6 +509,6 @@
/* FIXME: should be done using ntfs_* functions */
-void update_bootsector(s64 nr_clusters) {
-
+void update_bootsector(s64 nr_clusters)
+{
NTFS_BOOT_SECTOR bs;
|
|
From: Anton A. <ai...@ca...> - 2002-07-09 09:26:29
|
At 10:07 09/07/02, ? wrote:
>Changes by: szaka
>
>Update of /cvsroot/linux-ntfs/linux-ntfs/ntfstools
>In directory usw-pr-cvs1:/tmp/cvs-serv31866
>
>Modified Files:
> ntfsresize.c
>Log Message:
>Don't give up inode walking on EIO: temporary fix for not being
> able to distinguish corrupt and not FILE records easily)
>
>
>Index: ntfsresize.c
>===================================================================
>RCS file: /cvsroot/linux-ntfs/linux-ntfs/ntfstools/ntfsresize.c,v
>retrieving revision 1.3
>retrieving revision 1.4
>diff -U2 -r1.3 -r1.4
>--- ntfsresize.c 9 Jul 2002 00:00:19 -0000 1.3
>+++ ntfsresize.c 9 Jul 2002 09:07:10 -0000 1.4
>-int err_exit(const char *fmt, ...) {
>-
>+int err_exit(const char *fmt, ...)
>+{
Ah, thanks. (-:
>@@ -237,6 +237,9 @@
> for (inode = 0; inode < vol->nr_mft_records; inode++) {
> mref = (MFT_REF)inode;
>- if (ntfs_read_file_record(vol, mref, &mrec, NULL))
>- perr_exit("ntfs_read_file_record");
>+ if (ntfs_read_file_record(vol, mref, &mrec, NULL)) {
>+ if (errno == EIO)
>+ continue;
>+ perr_exit("ntfs_read_file_record");
>+ }
> if (!(mrec->flags & MFT_RECORD_IN_USE))
> continue;
Are you sure about this one? I am not. If you seen anything that is not a
FILE record you should not continue as you don't know what it means... It
usually means that either something is corrupt in the mft record or that
check disk was running and failed (power failed or whatever). In either
case you would not want to continue I think... If you want to work with
non-FILe records you really should use ntfs_read_mft_record() instead...
Can you tell me what records you found other than file? I have seen CHKD
(check disk), BAAD (corrupt mft record), and from the windows ntfs driver
source I know that HOLE is a valid record but I haven't seen it in the wild
yet and I was too lazy to figure out what it meant by reverse engineering it...
Anton
--
"I've not lost my mind. It's backed up on tape somewhere." - Unknown
--
Anton Altaparmakov <aia21 at cantab.net> (replace at with @)
Linux NTFS Maintainer / IRC: #ntfs on irc.openprojects.net
WWW: http://linux-ntfs.sf.net/ & http://www-stu.christs.cam.ac.uk/~aia21/
|
|
From: Szakacsits S. <sz...@si...> - 2002-07-09 14:46:42
|
On Tue, 9 Jul 2002, Anton Altaparmakov wrote:
> > for (inode = 0; inode < vol->nr_mft_records; inode++) {
> > mref = (MFT_REF)inode;
> >- if (ntfs_read_file_record(vol, mref, &mrec, NULL))
> >- perr_exit("ntfs_read_file_record");
> >+ if (ntfs_read_file_record(vol, mref, &mrec, NULL)) {
> >+ if (errno == EIO)
> >+ continue;
> >+ perr_exit("ntfs_read_file_record");
> >+ }
> > if (!(mrec->flags & MFT_RECORD_IN_USE))
> > continue;
>
> Are you sure about this one? I am not.
I'm sure it's temporary :) Sorry, I forgot the FIXME.
> Can you tell me what records you found other than file? I have
> seen CHKD (check disk), BAAD (corrupt mft record), and from the
> windows ntfs driver source I know that HOLE is a valid record but
> I haven't seen it in the wild yet and I was too lazy to figure out
> what it meant by reverse engineering it...
Unused (16-23) inodes on NTFS v3.0:
Inodes: 16,18,19 are like
0004000: 0100 0000 0000 0000 0000 0000 0000 0000 ................
0004010: 0000 0000 0000 0000 0000 0000 0000 0000 ................
*
00041f0: 0000 0000 0000 0000 0000 0000 0000 0100 ................
0004200: 0000 0000 0000 0000 0000 0000 0000 0000 ................
*
00043f0: 0000 0000 0000 0000 0000 0000 0000 0100 ................
Inode 17 is OK, FILE.
Inodes: 20-23 are like
0005400: 0000 0000 0000 0000 0000 0000 0000 0000 ................
*
00057f0: 0000 0000 0000 0000 0000 0000 0000 0000 ................
Or another case, inode 16 like in the first case, all other between
17-23 is ok, FILE.
Szaka
|
|
From: Anton A. <ai...@ca...> - 2002-07-09 14:57:35
|
On Tue, 9 Jul 2002, Szakacsits Szabolcs wrote:
> On Tue, 9 Jul 2002, Anton Altaparmakov wrote:
>
> > > for (inode = 0; inode < vol->nr_mft_records; inode++) {
> > > mref = (MFT_REF)inode;
> > >- if (ntfs_read_file_record(vol, mref, &mrec, NULL))
> > >- perr_exit("ntfs_read_file_record");
> > >+ if (ntfs_read_file_record(vol, mref, &mrec, NULL)) {
> > >+ if (errno == EIO)
> > >+ continue;
> > >+ perr_exit("ntfs_read_file_record");
> > >+ }
> > > if (!(mrec->flags & MFT_RECORD_IN_USE))
> > > continue;
> >
> > Are you sure about this one? I am not.
>
> I'm sure it's temporary :) Sorry, I forgot the FIXME.
>
> > Can you tell me what records you found other than file? I have
> > seen CHKD (check disk), BAAD (corrupt mft record), and from the
> > windows ntfs driver source I know that HOLE is a valid record but
> > I haven't seen it in the wild yet and I was too lazy to figure out
> > what it meant by reverse engineering it...
>
> Unused (16-23) inodes on NTFS v3.0:
>
> Inodes: 16,18,19 are like
> 0004000: 0100 0000 0000 0000 0000 0000 0000 0000 ................
> 0004010: 0000 0000 0000 0000 0000 0000 0000 0000 ................
> *
> 00041f0: 0000 0000 0000 0000 0000 0000 0000 0100 ................
> 0004200: 0000 0000 0000 0000 0000 0000 0000 0000 ................
> *
> 00043f0: 0000 0000 0000 0000 0000 0000 0000 0100 ................
>
> Inode 17 is OK, FILE.
>
> Inodes: 20-23 are like
> 0005400: 0000 0000 0000 0000 0000 0000 0000 0000 ................
> *
> 00057f0: 0000 0000 0000 0000 0000 0000 0000 0000 ................
>
> Or another case, inode 16 like in the first case, all other between
> 17-23 is ok, FILE.
System/special/reserved files. Typical. )-: Ok, we need to do something
about those... I think the best approach would be to special case inodes
0-23 and treat them specially. For them it is allowed to not have FILE in
which case you just need to skip them. But actually you should also make
sure that the magic isn't BAAD, CHKD, or HOLE. For either of these you
should abort for now at least. So the best way would be to use
read_mft_record and (pseudo code):
if (magic != FILE) {
if ((mft_no < 24) && (mft_no >= 16) &&
(magic != one of BAAD, CHKD, HOLE))
continue;
abort;
}
Best regards,
Anton
--
Anton Altaparmakov <aia21 at cantab.net> (replace at with @)
Linux NTFS maintainer / IRC: #ntfs on irc.openprojects.net
WWW: http://linux-ntfs.sf.net/ & http://www-stu.christs.cam.ac.uk/~aia21/
|
|
From: Szakacsits S. <sz...@si...> - 2002-07-11 09:32:23
|
On Tue, 9 Jul 2002, Anton Altaparmakov wrote:
>
> System/special/reserved files. Typical. )-: Ok, we need to do something
> about those...
Please note, resizer has an additional check mechanism: building his
own cluster bitmap and compares that with the on-disk cluster bitmap.
If they don't exactly match or a mapped cluster is referenced more
then once it will exit.
> I think the best approach would be to special case inodes 0-23 and
> treat them specially.
Apparently yes, also additionally or instead of checking the mft
bitmap if these inodes are used or not would be a way.
> For them it is allowed to not have FILE in which case you just
> need to skip them. But actually you should also make sure that the
> magic isn't BAAD, CHKD, or HOLE. For either of these you should
> abort for now at least. So the best way would be to use
> read_mft_record and (pseudo code):
>
> if (magic != FILE) {
> if ((mft_no < 24) && (mft_no >= 16) &&
> (magic != one of BAAD, CHKD, HOLE))
> continue;
> abort;
> }
Ok, I'll add additional checks.
Szaka
|
|
From: Szakacsits S. <sz...@si...> - 2002-07-12 13:36:25
|
On Tue, 9 Jul 2002, Anton Altaparmakov wrote: > Can you tell me what records you found other than file? I have > seen CHKD (check disk), BAAD (corrupt mft record), and from the > windows ntfs driver source I know that HOLE is a valid record but > I haven't seen it in the wild yet and I was too lazy to figure out > what it meant by reverse engineering it... Hmm, not much reference (1 at the definition) to HOLE however apparently there are some RSTR (probably meaning 'restore' especially their occurances are around CHKD). Szaka |
|
From: Anton A. <ai...@ca...> - 2002-07-12 15:55:29
|
On Fri, 12 Jul 2002, Szakacsits Szabolcs wrote: > On Tue, 9 Jul 2002, Anton Altaparmakov wrote: > > > Can you tell me what records you found other than file? I have > > seen CHKD (check disk), BAAD (corrupt mft record), and from the > > windows ntfs driver source I know that HOLE is a valid record but > > I haven't seen it in the wild yet and I was too lazy to figure out > > what it meant by reverse engineering it... > > Hmm, not much reference (1 at the definition) to HOLE however > apparently there are some RSTR (probably meaning 'restore' especially > their occurances are around CHKD). RSTR = ReSTaRt area. There are two such records at the beginning of $LogFile/$DATA attribute. Are you saying that you found a RSTR record in the $MFT/$DATA attribute? If yes, that would be a very interesting finding! Definitely something that would make me get fire up IDA Pro and search around the windows ntfs driver... Best regards, Anton -- Anton Altaparmakov <aia21 at cantab.net> (replace at with @) Linux NTFS maintainer / IRC: #ntfs on irc.openprojects.net WWW: http://linux-ntfs.sf.net/ & http://www-stu.christs.cam.ac.uk/~aia21/ |
|
From: Szakacsits S. <sz...@si...> - 2002-07-14 12:55:04
|
On Fri, 12 Jul 2002, Anton Altaparmakov wrote: > Are you saying that you found a RSTR record in the $MFT/$DATA attribute? No, just reference in the driver. Szaka |
|
From: Anton A. <ai...@ca...> - 2002-07-14 13:02:41
|
At 12:55 14/07/02, Szakacsits Szabolcs wrote: >On Fri, 12 Jul 2002, Anton Altaparmakov wrote: > > Are you saying that you found a RSTR record in the $MFT/$DATA attribute? > >No, just reference in the driver. Ah, ok. Nothing to worry about then. (-: Anton -- "I've not lost my mind. It's backed up on tape somewhere." - Unknown -- Anton Altaparmakov <aia21 at cantab.net> (replace at with @) Linux NTFS Maintainer / IRC: #ntfs on irc.openprojects.net WWW: http://linux-ntfs.sf.net/ & http://www-stu.christs.cam.ac.uk/~aia21/ |
