chmod() fails on HPFS386 in UnixEAs mode if the file is read-only

[dmik]

The following test cases shows the problem:

#include <stdio.h>
#include <stdlib.h>
#include <unistd.h>
#include <fcntl.h>
#include <sys/stat.h>

int main()
{
    int fd = open("test", O_RDONLY | O_CREAT | O_EXCL,
                  S_IRUSR | S_IRGRP | S_IROTH);
    if (fd == -1)
    {
        perror("open");
        return 1;
    }
    close(fd);

    if (chmod("test", S_IRUSR | S_IRGRP | S_IROTH) == -1)
        perror("chmod");
	
    return 0;
}

This does not happen on HPFS or on JFS (e.g. chmod() succeeds in this case).

[dmik]

Attached is a trivial fix that resets the FILE_READONLY bit before doing EAs.

[bird]

Note to self: Add a hpfs386 check to the fs.c code as well.

[dmik]

JFYI, there is a bunch of similar problems. For example, DosQueryFileInfo?(FIL_QUERYEASIZE) on a file opened with OPEN_ACCESS_WRITEONLY will also return ERROR_ACCESS_DENIED on HPFS386. The logic of the people who did that is understandable (they treat EAs as part of file data) but questionable. IMHO, EAs is the extension to the the standard attributes (DOS attributes, size, time, etc.) that can be read and modified regardless of whether the file is opened in read-only or write-only mode, and that makes more sense.

[dmik]

Note that there is also another related problem: calling DosQueryPathInfo(FIL_QUERYEASIZE) on a file which is open will fail with ERROR_SHARING_VIOLATION (32) on any file system, not only HPFS386. This breaks the following code which is perfectly valid on Linux:

int fd = open("foobar", O_RDWR | O_CREAT | O_EXCL | O_CLOEXEC, 0666);
// sometime later while fd is still open...
chmod("foobar", 0777);

Under kLIBC this expectedly fails with EACCESS. There is a workaround that may be applied in kLIBC: use DosQUeryFileInfo which succeeds in such a case. But in order to do so chmod needs to walk through the open file descriptor list to see if there is an open file for the given file path in the current process. Until then, the original Linux source needs to be changed to explicitly use fchmod that takes a file descriptor instead of a path as an argument (which is of course the proper way to do such a thing even on Linux since it's obviously faster).

[dmik]

See ​http://trac.netlabs.org/ports/ticket/183 for a real life example.