Mail Archives: djgpp-workers/1999/07/19/15:44:32
Bonjour
>
> I've seen code in some GNU package which seems to imply that
> `ftruncate' doesn't move the file pointer position.
That's correct.
> Our implementation does. I am not sure whether this is a bug in the
> GNU application or in our implementation. One Unix box says in
That's a bug in the implementation. The only affected fields
are st_time and st_mtime who are updated.
> the man page that the file pointer is left unaltered, but the rest
> keep silent. Could someone please see how does `ftruncate' behave
> on Unix/Linux?
Mostly ftruncate() was introduce to POSIX because of shared memory.
And in fact ftruncate() is only required if shared memory is being
supported.
>
> And while at that: since `ftruncate' is in man2, it probably means
> that it is a system call. If so, would it be reasonable to have a
> separate FSEXT number for it? I mean, some extensions could support
> truncation, but not lseek, right? Also, short of looking into
IMHO that would be good, if one decides to implement shared memory or
mmap() files, its good to have the mechanism in place.
> sources, there's no easy way for an application programmer to know
> that `ftruncate' is an `lseek' followed by `_write'. Comments?
>
How about if you are implementing map files or shared objects
fd = shm_open("/dev/phys/mem", O_CREAT|O_RDW, S_IRWXU)
ftruncate(fd, 1024);
ptr = mmap(0, 1024, PROT_READ|PROT_WRITE|MAP_SHARED, fd, 0);
close(fd);
fd2 = shm_open("/dev/ram", ....);
ftruncate(fd2, 4*1024);
A shared memory area, technically has zero size when first created.
You provide it to the underlying implementation via ftruncate().
An lseek()/write() will not do it, sometimes you want to create
a "hole" in the file by lseek()ing pass the size not ftruncate()ed
i.e. readjust its size.
--
alain
- Raw text -