jack23912 / grub4dos-chenall

Automatically exported from code.google.com/p/grub4dos-chenall
0 stars 0 forks source link

dd bug when (rd)+1 is used for input file #193

Closed GoogleCodeExporter closed 8 years ago

GoogleCodeExporter commented 8 years ago
What steps will reproduce the problem?

# fill (rd) with 0's , 0x82d0 is rd-base mem address, Fn24 is memset - fill 
memory  <addr> <string> <size>
map (md)0x21000+200 (rd) > nul ;; read 0x82d0 > nul ;; call Fn.24  %@retval% 
0x20  102400 > nul 

now fill a 29217 (0x7221) byte file on a NTFS partition (FAT32 not tested)

dd if=(rd)+1 of=()/_ISO/MyE2B.cfg

>> Bytes read / written = 0xA000 / 0x7221

now list file

cat --skip=0x1ff0 --length=0x80 --hex /_ISO/MyE2B.cfg

What is the expected output? What do you see instead?

dd only seems to overwrite first 0x2000 bytes in the file.

See screenshot.

What version of the product are you using? On what operating system?

0.4.5c Aug 2014

Please provide any additional information below.

Original issue reported on code.google.com by Steve6375 on 7 Aug 2014 at 2:28

Attachments:

GoogleCodeExporter commented 8 years ago
[deleted comment]
GoogleCodeExporter commented 8 years ago
very odd!

dd if=/_ISO/aliums.cfg of=/_ISO/MyE2B.cfg

even though it reports the whole file was read and written.

also only copies first 0x2000 bytes ????

Original comment by Steve6375 on 7 Aug 2014 at 2:45

GoogleCodeExporter commented 8 years ago
The file \_ISO\MyE2B.cfg was not contiguous.
It was an NTFS formatted partition.

I ran WinContig on the file to make it contiguous and now it works!!!

So dd does not work unless the file is contiguous on an NTFS file!

Original comment by Steve6375 on 7 Aug 2014 at 2:51

GoogleCodeExporter commented 8 years ago
P.S. I cannot check now, but I think I also tried

cat /_ISO/aliums.cfg > /_ISO/MyE2b.cfg

and that failed too ???

Original comment by Steve6375 on 7 Aug 2014 at 2:55

GoogleCodeExporter commented 8 years ago
[deleted comment]
GoogleCodeExporter commented 8 years ago
Maybe this issue should be called

writing more than 8K to a non-contiguous NTFS file does not work?

Original comment by Steve6375 on 7 Aug 2014 at 6:48

GoogleCodeExporter commented 8 years ago
I have spent a whole day trying to narrow down this bug!!
Finally I can do it. Instructions are inside Menu.lst file - please read.

Make an NTFS USB Flash drive.
Install grub4dos to MBR  (0.4.5c  Aug 2014 was used) and add \grldr
Use \menu.lst file in attached file
Follow instructions - you need to make a fragmented file by using copy /b s+s 
s1  in WINDOWS CONSOLE
Make many files (s1, s2, s3, s4 all same size as s1 by using same copy /b s+s 
s2  etc.)

Sn files MUST be fragmented (I have not found this bug on a non-fragmented file 
and when a 'bad' file is defragged the prblem goes away). It may happen on a 
contiguous file - I just have never seen it happen on a contiguous file.

Boot to grub4dos and run menu, enter the file path - e.g. /s1

check if 8K has 00's - if so then it has failed. see jpg attached.

Some files pass - some files fail.

e.g. if s2 fails, then it will always fail.
     if s1 passes then it will always pass.

There is some bug - not sure if bug is in NTFS

Also same problem with dd from a file

cat --length=0x100 --hex --skip=0x1f80 /README.txt
shows 
00001FF0 <text here>
00002000 <text here>

dd if=()/readme.txt of=()/s2
cat --length=0x100 --hex --skip=0x1f80 /s2

shows 
00001FF0 <readme text here>
00002000 00 00 00 00   00 00 00 00 00 00 00 00 00 00 00 00
00002010 00 00 00 00   00 00 00 00 00 00 00 00 00 00 00 00
etc.

all 0's and NOT original contents.

all 0's until C800 then was 55 to end of file C80C  (51213 bytes)
presumably 55 was left over from previous fill using the menu?

This issue happens when testing on real system or VBOX or QEMU.

Original comment by Steve6375 on 9 Aug 2014 at 8:32

Attachments:

GoogleCodeExporter commented 8 years ago
if specify blocklist instead of filename it works!

see jpg

Original comment by Steve6375 on 9 Aug 2014 at 8:46

Attachments:

GoogleCodeExporter commented 8 years ago
See Issue 172 - same problem with redirection if file is fragemented

Original comment by Steve6375 on 10 Aug 2014 at 7:43

GoogleCodeExporter commented 8 years ago
This is a large bug - can you reproduce it?
Let me know if you need more details.

Original comment by Steve6375 on 12 Aug 2014 at 9:22

GoogleCodeExporter commented 8 years ago
fixed in 2014-08-19 version

Original comment by Steve6375 on 19 Aug 2014 at 11:12

GoogleCodeExporter commented 8 years ago
I do nothing for this issue,Is it fixed?

Original comment by chenall.cn on 20 Aug 2014 at 12:14

GoogleCodeExporter commented 8 years ago
This is the NTFS bug fixed by tinybit  (writing to fragmented NTFS files had 
bug)

Original comment by Steve6375 on 20 Aug 2014 at 9:00

GoogleCodeExporter commented 8 years ago
Ok,close issue now.

Original comment by chenall.cn on 20 Aug 2014 at 10:27