1 files changed, 52 insertions, 0 deletions
diff --git a/results/classifier/118/graphic/567380 b/results/classifier/118/graphic/567380
new file mode 100644
index 000000000..7075adf25
--- /dev/null
+++ b/results/classifier/118/graphic/567380
@@ -0,0 +1,52 @@
+graphic: 0.922
+mistranslation: 0.913
+semantic: 0.858
+device: 0.807
+performance: 0.783
+files: 0.761
+architecture: 0.738
+network: 0.699
+PID: 0.665
+user-level: 0.658
+socket: 0.652
+kernel: 0.623
+hypervisor: 0.618
+ppc: 0.583
+register: 0.567
+permissions: 0.566
+boot: 0.545
+debug: 0.528
+risc-v: 0.508
+virtual: 0.492
+vnc: 0.491
+VMM: 0.490
+TCG: 0.468
+assembly: 0.468
+x86: 0.412
+peripherals: 0.399
+arm: 0.395
+i386: 0.277
+KVM: 0.269
+
+qemu-img fails to create images >= 4G
+
+On a Windows XP system and an NTFS drive, using QEMU on Windows Ver 0.12.2 from http://homepage3.nifty.com/takeda-toshiya/qemu/ or QEMU 0.12.3 or d3538b45ea88e82d1b01959b4ca55d3696b71cb2 built locally, when I run the following command, a zero-length file is created.
+
+ qemu-img create foo.img 4G
+
+Confirmed under Win 7 64-bit.
+Also does same thing on v10.6, v11.1, v12.1
+
+what a zero-length file means? Run the following command to see
+qemu-img info foo.img
+
+The file size was zero bytes (i.e., it contained no data).
+
+I've tried again with QEMU 2.6.50 on a Windows 7 Professional system and it appears to have created the s 
+
+Sorry, I accidentally submitted comment #3 without finishing it.
+
+I was going to say that when I tried QEMU 2.6.50 on a Windows 7 Professional system, it appears to have created the image file successfully.
+
+Thanks for the update ... since it is working with the current version of QEMU, I assume this problem has been fixed sometimes during the past years, thus we can close this ticket now.
+