Mail Archives: djgpp-workers/2003/02/25/09:08:10
Hello.
Eli Zaretskii wrote:
>
> > Date: Thu, 20 Feb 2003 14:29:55 +0000
> > From: Richard Dawe <rich AT phekda DOT freeserve DOT co DOT uk>
[snip]
> > It seems like you can change the file attributes from, say, read-write to
> > read-only on a file that was opened for read-write and still write to it:
> >
> > open for read-write
> > write to file
> > change attributes to read-only
> > write to file
> > close file
> >
> > None of this fails on Windows '98 SE.
>
> This should be documented, I think, since Posix systems behave
> differently.
I've looked at draft 7 for new POSIX. It doesn't talk about what happens to
I/O through the file descriptor, when you change the permissions on an open
file descriptor. It only talks about the changes to the file identified by the
descriptor.
It seems like this is implementation-dependent.
FWIW Linux allows writes to the file, after fchmod'ing to be read-only. The
test program at the end of this mail works fine on Linux. The file is
read-only afterwards.
> > I suspect it will fail under DOS, where the LFN API is not present and
> > there is no extended create call. I have not done any testing yet.
>
> Could someone please see what does DOS do with that? W2K/XP might
> also behave differently.
I'll post a patch, so that people can test.
> > Here's what I've implemented so far:
> >
> > let fsext handle it, if it wants
> >
> > if it's a character device, ignore the request and return success
> >
> > try to find out current permissions - if they match the requested ones,
> > just return
> >
> > if no filename is known from fd_props, fail with errno == ENOENT
> >
> > otherwise do a chmod on the filename
>
> This sounds okay.
I thought about returning ENOSYS instead of ENOENT. I think you suggested this
before. But this would be misleading, I think. I take ENOSYS to mean that the
system call is not implemented at all, whereas we've partially implemented it.
So I think ENOENT is right.
We are also allowed to return EINVAL, when fchmod is called on pipes, as
described by the Single Unix Specification v2. This could be useful for the
standard handles, when they are redirected. But how do we detect that standard
handles are piped? fd_props has a FILE_DESC_PIPE flag, but can we rely on
that? Is returning EINVAL actually any better than returning ENOENT for
redirection? I don't think so.
Thanks, bye, Rich =]
--
Richard Dawe [ http://www.phekda.freeserve.co.uk/richdawe/ ]
---Start test program---
#include <stdio.h>
#include <stdlib.h>
#include <fcntl.h>
#include <sys/stat.h>
#include <unistd.h>
const char test_file[] = "t-fchmod.tst";
int
main (int argc, char *argv[])
{
int fd;
unlink(test_file);
fd = open(test_file, O_RDWR|O_EXCL|O_CREAT, S_IRUSR|S_IWUSR);
if (fd < 0)
{
perror(argv[0]);
return(EXIT_FAILURE);
}
close(fd);
fd = open(test_file, O_RDWR);
if (fd < 0)
{
perror(argv[0]);
return(EXIT_FAILURE);
}
{
const char buf[] = "foo";
if (write(fd, buf, strlen(buf)) < 0)
{
close(fd);
perror(argv[0]);
return(EXIT_FAILURE);
}
}
if (fchmod(fd, S_IRUSR) < 0)
{
perror(argv[0]);
return(EXIT_FAILURE);
}
{
const char buf[] = "foo";
if (write(fd, buf, strlen(buf)) < 0)
{
close(fd);
perror(argv[0]);
return(EXIT_FAILURE);
}
}
close(fd);
return(EXIT_SUCCESS);
}
---End program---
- Raw text -