On Monday 25 February 2008 12:26, Bob Proulx <[EMAIL PROTECTED]> wrote: > There is always 'head'. > > head --bytes=1024m
That doesn't do what I want at all. It creates a new file, which is an entirely different thing, it uses temporary file space (in the above example it won't work unless there is 1G of free space), and it can't deal with holes and therefore won't work on sparse files for that reason alone. Also consider the case of a multi-terabyte sparse file, even if you have spare disk space the time taken to copy the file will be immense. > Let me guess. You have a partially downloaded image with a corrupted > part at the end that you want to modify so that the download can > resume from a known good state? No. One thing I want to do is to resize Xen images. Another thing I want to do is to create large sparse files. > I think the functionality is interesting but don't know where the best > place to locate it. The dd program actually does seem like a good > place for this to go. dd copies data, it doesn't adjust file sizes. Doing this correctly requires three system calls, open(), ftruncate(), and close() and no functionality that is currently in dd (which calls ftruncate() only for the purpose of setting the file size to the output size and only in some situations). dd can create large sparse files with the seek= option, but that's awkward, not obvious to casual users, and generally inconvenient. > I think I would favor putting it there. But > otherwise a completely new program with general file handling features > might not be a bad idea. Many of the existing programs already have a > large amount of bloat and it is better not to keep dumping the kitchen > sink of things into them. Yes, particularly when a program named truncate(1) would be a good complement to truncate(2). -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
