Hi!
> It could be used as a replacement for the truncate code, because then
> truncate is simply a special case of punch, namely punch(0, end).
I do not think so. Truncate leaves you with filesize 0, while punch schould
leave you with filesize of original file.
Phil writes:
> though looking and grepping through the sources I couldn't find a way (via
> fcntl() or whatever) to allow an existing file to get holes.
>
> What I'd like to do is something like
>
> fh=open( ... , O_RDWR);
> lseek(fh, position ,SEEK_START);
> // where position is a multiple
On Friday 29 June 2001 14:55, Ph. Marek wrote:
> Hmmm, on second thought ... But I'd like it better to have a fcntl for
> hole-making :-)
> Maybe I'll implement this myself.
A far superior interface would be:
ssize_t sys_clear(unsigned int fd, size_t count)
A stub implementation would just
>For your specific problem I'd suggest the following approach:
>
>write a new filter prog, kind of a 'destructive cat' command.
>
>Open the file for read-modify (non destructive)
>Let it read some blocks (number controllable on commandline) from the
>beginning and pipe them to stdout. Then.. read
On Fri, 29 Jun 2001, Ph. Marek wrote:
> Hi everybody,
>
> though looking and grepping through the sources I couldn't find a way (via
> fcntl() or whatever) to allow an existing file to get holes.
Indeed, I don't think there is any such syscall.
> I found that cp has a parameter --sparse (or su
Hi everybody,
though looking and grepping through the sources I couldn't find a way (via
fcntl() or whatever) to allow an existing file to get holes.
I found that cp has a parameter --sparse (or suchlike) - but strace shows
it doing a open(,O_TRUNC) which has a bit of impact on previous filedata
6 matches
Mail list logo
