Re: VFAT i_pos value

2011-12-09 Thread OGAWA Hirofumi
Kai Meyer k...@gnukai.com writes:

 [root@dev1 sblsnap]# ./vfat_entry /dev/sblsnap0 523781
 block 4092, sector 32736, offset 5
 name  3~1 ZER
 attr  32
 lcase 0
 ctime_cs  100
 ctime 29092
 cdate 16264
 adate 16264
 starthi   4
 time  29092
 date  16264
 start 7427
 size  37748736
 next pos: 32736

Looks like sane entry.

 [root@dev1 sblsnap]# ./vfat_entry /dev/sblsnap0 32736
 block 255, sector 2040, offset 96
 name
 attr  0
 lcase 0
 ctime_cs  0
 ctime 0
 cdate 0
 adate 0
 starthi   0
 time  0
 date  0
 start 0
 size  0
 next pos: 2040

 Does that look like what would be causing my error? meaning, sector 2040 
 has bad data?

The next pos means the position of data cluster (i.e that entry is using
the cluster of this position to store data). You have to walk the
cluster position chain on FAT table, not directory entry.
-- 
OGAWA Hirofumi hirof...@mail.parknet.co.jp

___
Kernelnewbies mailing list
Kernelnewbies@kernelnewbies.org
http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies


Re: VFAT i_pos value

2011-12-08 Thread Kai Meyer


On 12/02/2011 11:23 PM, OGAWA Hirofumi wrote:
 OGAWA Hirofumihirof...@mail.parknet.co.jp  writes:

 Kai Meyerk...@gnukai.com  writes:

 Thanks for the helpful response. I'm not entirely sure I understand the
 next part though. I hacked a dirty entry dumper tool:

 #includestdio.h
 #includelinux/msdos_fs.h
 #includesys/types.h
 #includesys/stat.h
 #includefcntl.h
 #includeunistd.h
 #includestring.h

 int main(int argc, char** argv)
 {
   off_t pos = atoi(argv[2]);
   unsigned long block;
   off_t sector;
   unsigned int offset;
   int fd = open(argv[1], O_RDONLY);
   char buf[512];
   struct msdos_dir_entry dirent;
   block = pos / (4096 / 32);
   sector = block * 8;
   offset = pos % (4096 / 32);
   printf(block %lu, sector %lu, offset %u\n, block, sector,
 offset);
   lseek(fd, sector * 512, SEEK_SET);
   if (read(fd, buf, 512)  0) {
   fprintf(stderr, Unable to read from device %s\n,
 argv[1]);
   return -1;
   }
   memcpy(dirent, buf + offset, sizeof(dirent));
   printf(name  %s\n, dirent.name);
   printf(attr  %u\n, dirent.attr);
   printf(lcase %u\n, dirent.lcase);
   printf(ctime_cs  %u\n, dirent.ctime_cs);
   printf(ctime %u\n, dirent.ctime);
   printf(cdate %u\n, dirent.cdate);
   printf(adate %u\n, dirent.adate);
   printf(starthi   %u\n, dirent.starthi);
   printf(time  %u\n, dirent.time);
   printf(date  %u\n, dirent.date);
   printf(start %u\n, dirent.start);
   printf(size  %u\n, dirent.size);
 }

 Here's what it outputs:

 ./vfat_entry /dev/sblsnap0 523793
 block 4092, sector 32736, offset 17
 name
 attr  255
 lcase 255
 ctime_cs  255
 ctime 12799
 cdate 12670
 adate 8224
 starthi   8224
 time  23072
 date  21061
 start 32
 size  2171155456

 So, I take starthi, and shift 16 bits left, then and in the start value.
 That should give me the byte address of the first cluster of the file,
 correct?

 Then I need to follow the cluster chain until I get a bad value.
 It looks like wrong as dirent. Did you use 523793 really? If so, I think
 523791 is correct value. :)
 And I didn't mention about offset correctly. offset means number of
 entries, not bytes offset. So, bytes offset is buf + offset * 32.
 (32 == sizeof(struct msdos_dir_entry))

 Thanks.
Ok, I fixed the buf + offset * 32. I have a new volume, so the error is now:
fat_get_cluster: invalid cluster chain (i_pos 523781)

I added a few lines at the end to print the start value:
 pos = dirent.starthi  16;
 pos |= dirent.start;
 printf(next pos: %u\n, sector);

[root@dev1 sblsnap]# ./vfat_entry /dev/sblsnap0 523781
block 4092, sector 32736, offset 5
name  3~1 ZER
attr  32
lcase 0
ctime_cs  100
ctime 29092
cdate 16264
adate 16264
starthi   4
time  29092
date  16264
start 7427
size  37748736
next pos: 32736
[root@dev1 sblsnap]# ./vfat_entry /dev/sblsnap0 32736
block 255, sector 2040, offset 96
name
attr  0
lcase 0
ctime_cs  0
ctime 0
cdate 0
adate 0
starthi   0
time  0
date  0
start 0
size  0
next pos: 2040

Does that look like what would be causing my error? meaning, sector 2040 
has bad data?

___
Kernelnewbies mailing list
Kernelnewbies@kernelnewbies.org
http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies


Re: VFAT i_pos value

2011-12-02 Thread OGAWA Hirofumi
Kai Meyer k...@gnukai.com writes:

 Thanks for the helpful response. I'm not entirely sure I understand the 
 next part though. I hacked a dirty entry dumper tool:

 #include stdio.h
 #include linux/msdos_fs.h
 #include sys/types.h
 #include sys/stat.h
 #include fcntl.h
 #include unistd.h
 #include string.h

 int main(int argc, char** argv)
 {
  off_t pos = atoi(argv[2]);
  unsigned long block;
  off_t sector;
  unsigned int offset;
  int fd = open(argv[1], O_RDONLY);
  char buf[512];
  struct msdos_dir_entry dirent;
  block = pos / (4096 / 32);
  sector = block * 8;
  offset = pos % (4096 / 32);
  printf(block %lu, sector %lu, offset %u\n, block, sector, 
 offset);
  lseek(fd, sector * 512, SEEK_SET);
  if (read(fd, buf, 512)  0) {
  fprintf(stderr, Unable to read from device %s\n, 
 argv[1]);
  return -1;
  }
  memcpy(dirent, buf + offset, sizeof(dirent));
  printf(name  %s\n, dirent.name);
  printf(attr  %u\n, dirent.attr);
  printf(lcase %u\n, dirent.lcase);
  printf(ctime_cs  %u\n, dirent.ctime_cs);
  printf(ctime %u\n, dirent.ctime);
  printf(cdate %u\n, dirent.cdate);
  printf(adate %u\n, dirent.adate);
  printf(starthi   %u\n, dirent.starthi);
  printf(time  %u\n, dirent.time);
  printf(date  %u\n, dirent.date);
  printf(start %u\n, dirent.start);
  printf(size  %u\n, dirent.size);
 }

 Here's what it outputs:

 ./vfat_entry /dev/sblsnap0 523793
 block 4092, sector 32736, offset 17
 name
 attr  255
 lcase 255
 ctime_cs  255
 ctime 12799
 cdate 12670
 adate 8224
 starthi   8224
 time  23072
 date  21061
 start 32
 size  2171155456

 So, I take starthi, and shift 16 bits left, then and in the start value. 
 That should give me the byte address of the first cluster of the file, 
 correct?

 Then I need to follow the cluster chain until I get a bad value.

It looks like wrong as dirent. Did you use 523793 really? If so, I think
523791 is correct value. :)
-- 
OGAWA Hirofumi hirof...@mail.parknet.co.jp

___
Kernelnewbies mailing list
Kernelnewbies@kernelnewbies.org
http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies


Re: VFAT i_pos value

2011-12-01 Thread OGAWA Hirofumi
Kai Meyer k...@gnukai.com writes:

 I'm getting this error:
 FAT: Filesystem error (dev sblsnap0)
  fat_get_cluster: invalid cluster chain (i_pos 523791)

 I'm wondering if there was a way to figure out what sector is causing 
 the error? I would like to try and track down what is changing that 
 sector and fix the problem. Is there a straight forward way to convert 
 i_pos to a sector value? I've been staring at the fat.c and fat.h code 
 all morning, and I'm having trouble grok'ing the flow.

The i_pos means directory entry (contains inode information in unix-fs)
position,

block number == i_pos / (logical-blocksize / 32)
offset   == i_pos  (logical-blocksize / 32)

the above position's directory entry contains information for
problematic file. This is how to use i_pos information.

FWIW, in this error case, the cluster chain in FAT table which is
pointed by that entry, it has invalid cluster value.

Thanks.
-- 
OGAWA Hirofumi hirof...@mail.parknet.co.jp

___
Kernelnewbies mailing list
Kernelnewbies@kernelnewbies.org
http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies


Re: VFAT i_pos value

2011-12-01 Thread Kai Meyer
On 12/01/2011 07:38 AM, OGAWA Hirofumi wrote:
 Kai Meyerk...@gnukai.com  writes:

 I'm getting this error:
 FAT: Filesystem error (dev sblsnap0)
   fat_get_cluster: invalid cluster chain (i_pos 523791)

 I'm wondering if there was a way to figure out what sector is causing
 the error? I would like to try and track down what is changing that
 sector and fix the problem. Is there a straight forward way to convert
 i_pos to a sector value? I've been staring at the fat.c and fat.h code
 all morning, and I'm having trouble grok'ing the flow.
 The i_pos means directory entry (contains inode information in unix-fs)
 position,

  block number == i_pos / (logical-blocksize / 32)
  offset   == i_pos  (logical-blocksize / 32)

 the above position's directory entry contains information for
 problematic file. This is how to use i_pos information.

 FWIW, in this error case, the cluster chain in FAT table which is
 pointed by that entry, it has invalid cluster value.

 Thanks.

If you would verify my math for me, I would appreciate it.

In this case, my logical block size is 4096, because byte 13 of the 8Gb 
file system is 8, and I take that to be 8 * 512, which is 4096. So:

block_number = 523791 / (4096 / 32) = 4092
offset = 523791 % (4096 / 32) = 15  // I assume you meant modulo in your 
original post, and not binary AND.

So if the block_number is 4092, I would multiply that by 8 (sectors per 
logical block) to get the sector number:
32736

Does the error indicate that sector contains the corrupted data? Or is 
it the sector that contains the information that points to the corrupted 
data? Or is it something entirely different?

-Kai Meyer

___
Kernelnewbies mailing list
Kernelnewbies@kernelnewbies.org
http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies


Re: VFAT i_pos value

2011-12-01 Thread OGAWA Hirofumi
Kai Meyer k...@gnukai.com writes:

 The i_pos means directory entry (contains inode information in unix-fs)
 position,

  block number == i_pos / (logical-blocksize / 32)
  offset   == i_pos  (logical-blocksize / 32)

 the above position's directory entry contains information for
 problematic file. This is how to use i_pos information.

 FWIW, in this error case, the cluster chain in FAT table which is
 pointed by that entry, it has invalid cluster value.

 Thanks.

 If you would verify my math for me, I would appreciate it.

 In this case, my logical block size is 4096, because byte 13 of the 8Gb 
 file system is 8, and I take that to be 8 * 512, which is 4096. So:

 block_number = 523791 / (4096 / 32) = 4092
 offset = 523791 % (4096 / 32) = 15  // I assume you meant modulo in your 
 original post, and not binary AND.

Whoops, you are right. (I forgot -1)

 So if the block_number is 4092, I would multiply that by 8 (sectors per 
 logical block) to get the sector number:
 32736

Right.

 Does the error indicate that sector contains the corrupted data?

No.

 Or is it the sector that contains the information that points to the
 corrupted data?

Right.

The i_pos is pointing a directory entry (include/linux/msdos_fs.h:
struct msdos_dir_entry).

And starthi (if FAT32) and start contain the pointer to next cluster
number. That message was outputted when walking in cluster chain.

If you want to see actual corrupted data, you can check the cluster
chain by pointing from that directory entry.

Thanks.
-- 
OGAWA Hirofumi hirof...@mail.parknet.co.jp

___
Kernelnewbies mailing list
Kernelnewbies@kernelnewbies.org
http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies


Re: VFAT i_pos value

2011-12-01 Thread Kai Meyer


On 12/01/2011 12:20 PM, OGAWA Hirofumi wrote:
 Kai Meyerk...@gnukai.com  writes:

 The i_pos means directory entry (contains inode information in unix-fs)
 position,

   block number == i_pos / (logical-blocksize / 32)
   offset   == i_pos   (logical-blocksize / 32)

 the above position's directory entry contains information for
 problematic file. This is how to use i_pos information.

 FWIW, in this error case, the cluster chain in FAT table which is
 pointed by that entry, it has invalid cluster value.

 Thanks.
 If you would verify my math for me, I would appreciate it.

 In this case, my logical block size is 4096, because byte 13 of the 8Gb
 file system is 8, and I take that to be 8 * 512, which is 4096. So:

 block_number = 523791 / (4096 / 32) = 4092
 offset = 523791 % (4096 / 32) = 15  // I assume you meant modulo in your
 original post, and not binary AND.
 Whoops, you are right. (I forgot -1)

 So if the block_number is 4092, I would multiply that by 8 (sectors per
 logical block) to get the sector number:
 32736
 Right.

 Does the error indicate that sector contains the corrupted data?
 No.

 Or is it the sector that contains the information that points to the
 corrupted data?
 Right.

 The i_pos is pointing a directory entry (include/linux/msdos_fs.h:
 struct msdos_dir_entry).

 And starthi (if FAT32) and start contain the pointer to next cluster
 number. That message was outputted when walking in cluster chain.

 If you want to see actual corrupted data, you can check the cluster
 chain by pointing from that directory entry.

 Thanks.

Thanks for the helpful response. I'm not entirely sure I understand the 
next part though. I hacked a dirty entry dumper tool:

#include stdio.h
#include linux/msdos_fs.h
#include sys/types.h
#include sys/stat.h
#include fcntl.h
#include unistd.h
#include string.h

int main(int argc, char** argv)
{
 off_t pos = atoi(argv[2]);
 unsigned long block;
 off_t sector;
 unsigned int offset;
 int fd = open(argv[1], O_RDONLY);
 char buf[512];
 struct msdos_dir_entry dirent;
 block = pos / (4096 / 32);
 sector = block * 8;
 offset = pos % (4096 / 32);
 printf(block %lu, sector %lu, offset %u\n, block, sector, 
offset);
 lseek(fd, sector * 512, SEEK_SET);
 if (read(fd, buf, 512)  0) {
 fprintf(stderr, Unable to read from device %s\n, 
argv[1]);
 return -1;
 }
 memcpy(dirent, buf + offset, sizeof(dirent));
 printf(name  %s\n, dirent.name);
 printf(attr  %u\n, dirent.attr);
 printf(lcase %u\n, dirent.lcase);
 printf(ctime_cs  %u\n, dirent.ctime_cs);
 printf(ctime %u\n, dirent.ctime);
 printf(cdate %u\n, dirent.cdate);
 printf(adate %u\n, dirent.adate);
 printf(starthi   %u\n, dirent.starthi);
 printf(time  %u\n, dirent.time);
 printf(date  %u\n, dirent.date);
 printf(start %u\n, dirent.start);
 printf(size  %u\n, dirent.size);
}

Here's what it outputs:

./vfat_entry /dev/sblsnap0 523793
block 4092, sector 32736, offset 17
name
attr  255
lcase 255
ctime_cs  255
ctime 12799
cdate 12670
adate 8224
starthi   8224
time  23072
date  21061
start 32
size  2171155456

So, I take starthi, and shift 16 bits left, then and in the start value. 
That should give me the byte address of the first cluster of the file, 
correct?

Then I need to follow the cluster chain until I get a bad value.

Thanks

___
Kernelnewbies mailing list
Kernelnewbies@kernelnewbies.org
http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies


Re: VFAT i_pos value

2011-11-30 Thread Abhijit Hoskeri
On Wed, Nov 30, 2011 at 2:33 PM, Kai Meyer k...@gnukai.com wrote:
 I'm getting this error:
 FAT: Filesystem error (dev sblsnap0)
     fat_get_cluster: invalid cluster chain (i_pos 523791)

Do you know what file this error is related to?

If you do, then you could see which blocks belong to the file and
calculate the block based on the above offset and the filesystem block size.

Regards,
Abhijit

___
Kernelnewbies mailing list
Kernelnewbies@kernelnewbies.org
http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies