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/[email protected]/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
[email protected]
http://lists.nongnu.org/mailman/listinfo/qemu-devel
