Pádraig Brady wrote: > Eric Sandeen wrote: ... >> TBH I think "truncate --allocate" sounds a little odd. (Now that I >> think back, I think I mentioned this before). truncate(1) and >> truncate(2) specifically refer to i_size, which to fs people like me, >> has nothing to do with the actual blocks allocated to a file. > > Well truncate(2) does, but I think truncate(1) is higher level > and is used to "set the size of a file". But "size of a file" in the truncate sense only means "set the EOF offset." "size of the file" in the truncate sense doesn't imply blocks or disk space - this is what allocation does. (blocks * blocksize) can be more than, less than, or same as the "size" (max offset) of the file, even after you truncate up or down. and indeed, # truncate --size 1k blah does just open("blah", O_WRONLY|O_CREAT|O_NONBLOCK, 0666) = 3 ftruncate(3, 1024) = 0 truncate(1) is just a handy userspace interface to truncate(2). Making it do anything else is just confusing well-defined interfaces & semantics, imho. I guess I don't -really- care if "truncate" grows an "--allocate" option, but I'd still like to see a nice "fallocate" in util-linux-ng ;) Thanks, -Eric > In that context an > --allocate option seems to fit I think. Also truncate(2) is > required to shrink an fallocated file. > > cheers, > Pádraig. -- To unsubscribe from this list: send the line "unsubscribe util-linux-ng" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html