From: Alexander Viro viro@math.psu.edu
Subject: [9fans] truncate syscall
Date: Mon, 10 Apr 2000 13:41:29 -0400 [thread overview]
Message-ID: <20000410174129.QxpoBi4P1vjhFLz4-KXmKoQNva-9ejgyoDF71Zk1hSA@z> (raw)
On Mon, 10 Apr 2000, Tom Duff wrote:
> > mmap(). truncate() is a bad name - it's setsize(). IOW, it can extend
> > files. Add the mmap() semantics in that respect and there you go -
> > open()/ftruncate() to set the size/mmap() the region/start working; is
> > quite common. Yes, you can kludge around it with lseek();write(); but
> > that's a kludge, unless we accept that zero-length write() changes the
> > file size. Which is not true under a lot of Unices (I seriously suspect
> > that it's explicitly prohibited by POSIX or something like that).
>
> int f=create("file", OREAD, 0666);
> if(n){
> seek(f, n-1, 0);
> write(f, "", 1);
> }
>
> What exactly is kludgy about this?
Almost noting (except that you may want to change the size of existing
file and thus it turns into lseek(...,SEEK_END) and comparing the sizes).
However, I suspect that I know the reason why this question appeared -
implementation of 9p _client_. And ->setattr() or equivalents in many
variants of VFS allow changing the size. So it boils down to graceful
error value or finding a way to do it over 9p...
> I've been using UNIX & Plan 9 for 26 years,
> and not once have I wanted to chop the tail
> off a file. I find it really hard to believe
> that you need this so badly that you want to
> change 9p. Why can't you afford to rewrite
> the file?
Usually OK for applications, but putting this kind of code into the
kernel... Ewww...
next reply other threads:[~2000-04-10 17:41 UTC|newest]
Thread overview: 13+ messages / expand[flat|nested] mbox.gz Atom feed top
2000-04-10 17:41 Alexander [this message]
-- strict thread matches above, loose matches on Subject: below --
2000-04-11 7:12 Bengt
2000-04-10 18:01 Tom
2000-04-10 17:59 gdb
2000-04-10 17:36 Tom
2000-04-10 17:36 Tom
2000-04-10 17:18 Tom
2000-04-10 17:00 Alexander
2000-04-10 16:51 Scott
2000-04-10 16:45 jmk
2000-04-10 16:23 gdb
2000-04-10 15:48 Russ
2000-04-10 13:33 Roman
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20000410174129.QxpoBi4P1vjhFLz4-KXmKoQNva-9ejgyoDF71Zk1hSA@z \
--to=9fans@9fans.net \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).