On 01/31/2018 01:36 PM, Michal Suchánek wrote: > On Wed, 20 Dec 2017 21:57:00 -0500 > John Snow <[email protected]> wrote: > >> On 12/20/2017 05:31 AM, Dr. David Alan Gilbert wrote: >>> Yep, can repeat it here, it seems pretty random which error it >>> gives: >>> >>> [dgilbert@dgilbert-t530 try]$ ./x86_64-softmmu/qemu-system-x86_64 >>> -cdrom /tmp qemu-system-x86_64: -cdrom /tmp: Could not refresh >>> total sector count: Invalid argument [dgilbert@dgilbert-t530 >>> try]$ ./x86_64-softmmu/qemu-system-x86_64 -cdrom /var >>> qemu-system-x86_64: -cdrom /var: Could not read image for >>> determining its format: File too large >>> >>> >>> ** Changed in: qemu >>> Status: New => Confirmed >>> >> >> Looks like directories play funny games. >> > > ... > >> specifically: >> >> (gdb) s >> 1963 size = lseek(s->fd, 0, SEEK_END); >> (gdb) s >> 1964 if (size < 0) { >> (gdb) print size >> $37 = 9223372036854775807 >> >> cool, cool, cool. This value is 0x7fffffffffffffff and errno isn't >> set. cool and good function. > > Indeed: The behavior of lseek() on devices which are incapable of > seeking is implementation-defined. > >> >> so, lseek on a folder returns crazy nonsense. Perhaps we ought to >> actually specifically disallow folders, we don't appear to. > > It probably returns -1 which it is supposed to do on error. It should > also set errno in that case, though. > > So this is probably bug in the error handling code in lseek. > > Thanks > > Michal >
Thanks. It looks like we can't make stronger guarantees about the behavior of lseek, so I submitted a patch to ratchet down QEMU's acceptable file types: https://lists.gnu.org/archive/html/qemu-devel/2018-01/msg05055.html Thanks, --John
