Pádraig Brady wrote: > Eric Sandeen wrote: >> 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." > > I don't see a problem in extending the meaning of the truncate command. > Now truncate isn't the best name for the command but that name > already existed in BSD and so I thought it best to align with that. > So what about also having an fallocate command in coreutils? > Well it would benefit from all the existing options of the truncate command, > I.E. would share most of the code, so I'm not convinced. Well, truncate is indeed a great name for a command that truncates. :) Does truncate do more than that in bsd? >> 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 ;) > > A reason to have this functionality in coreutils is that the core > functionality of posix_fallocate() is not linux specific. > Also fallocate() like functionality is exposed on solaris > for example through fcntl(fd, F_ALLOCSP, ...). Ok, having an aptly-named block-allocation-tool in coreutils sounds reasonable, if it the core functionality that can be supported across several OSes. > BTW I think your fallocate util might benefit from > calling truncate(2) to allow one to shrink files also? No, that's what truncate(1) is for IMHO. "Do one thing and do it well," right? :) -Eric > 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
