Closed GoogleCodeExporter closed 9 years ago
[deleted comment]
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
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
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
[deleted comment]
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
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:
if specify blocklist instead of filename it works!
see jpg
Original comment by Steve6375
on 9 Aug 2014 at 8:46
Attachments:
See Issue 172 - same problem with redirection if file is fragemented
Original comment by Steve6375
on 10 Aug 2014 at 7:43
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
fixed in 2014-08-19 version
Original comment by Steve6375
on 19 Aug 2014 at 11:12
I do nothing for this issue,Is it fixed?
Original comment by chenall.cn
on 20 Aug 2014 at 12:14
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
Ok,close issue now.
Original comment by chenall.cn
on 20 Aug 2014 at 10:27
Original issue reported on code.google.com by
Steve6375
on 7 Aug 2014 at 2:28Attachments: