On Mon, May 08, 2006 at 08:36:15PM -0500, Anthony Liguori wrote: > Jim C. Brown wrote: > >Aactually, the bug is in vfat not in qemu-img. > > > > Not really. POSIX doesn't mandate that ftruncate() increase a file > size. This is a Linux-ism and is only valid for filesystems that > support holes (which vfat doesn't). > > Regards, > > Anthony Liguori >
Ok, so in that case this is something qemu-img should handle on its own then. (Since we're not likely to see a "fix" in either glibc or the kernel for this, and it has the potential to be a portability issue.) On Mon, May 08, 2006 at 07:50:24PM -0400, Jim C. Brown wrote: > qemu-img correctly uses ftruncate() which is suppose to make the file sparse > if the underlying filesystem supports it, but it should fall back to adding > zeros > to the end of the file. On vfat you aren't able to seek past the end of a file > period, so this doesn't work. Turns out I was wrong about this too. http://www.mail-archive.com/bug-tar@gnu.org/msg00556.html Here is a patch that silently handles the Linux/vfat case using lseek(). -- Infinite complexity begets infinite beauty. Infinite precision begets infinite perfection.
--- block.c Tue May 16 13:06:15 2006 +++ block.c Tue May 16 13:07:51 2006 @@ -753,6 +753,20 @@ close(s->fd); } +int qemu_ftruncate(int fd, off_t length) +/* ftruncate() isn't guarranteed to grow a file, according to POSIX. ** +** This is. */ +{ + int res = ftruncate(fd, length); + if (res && (errno == EPERM)) + { + if ((lseek( fd, length - 1, SEEK_SET) == (off_t)-1) || + (write(fd, "\0", 1) == -1)) + return -1; + } + return res; +} + static int raw_create(const char *filename, int64_t total_size, const char *backing_file, int flags) { @@ -765,7 +779,7 @@ 0644); if (fd < 0) return -EIO; - ftruncate(fd, total_size * 512); + qemu_ftruncate(fd, total_size * 512); close(fd); return 0; }
_______________________________________________ Qemu-devel mailing list Qemu-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/qemu-devel