Related
I am trying to understand flags and modes of file descriptors.
The man page for
fcntl - manipulate file descriptor
int fcntl(int fd, int cmd);
states:
File descriptor flags
The following commands manipulate the flags associated with a file
descriptor. Currently, only one such flag is defined: FD_CLOEXEC,...
File status flags
Each open file description has certain associated status flags,
initialized by open(2)...
The file status flags and their semantics are described in open(2).
Given that fcntl refers entirely to file descriptors (no dealing with streams), I guess the second title should be "File descriptor status flags".
So now we have for a FD "flags" and "status flags".
This man page also mentions that when cmd=F_GETFL, the return value of fcntl is "the file access mode and the file status flags".
So now we have also a file access mode.
Now in the man page for open
there are flags and modes, as if they were two different items.
There is even a prototype that makes explicit the difference
int open(const char *pathname, int flags, mode_t mode);
So now we have, for each file descriptor, "flags", "status flags", "file access modes", and "modes" (I would identify the latter two as the same).
To begin with,
1. I don't know the difference between these three categories.
Traversing both quoted man pages, I collected a list of "entities" (below, in order of appearance, some are repeated).
2. I don't know which category each belongs to.
FD_CLOEXEC, O_RDONLY, O_WRONLY, O_RDWR, O_CREAT, O_EXCL, O_NOCTTY, O_TRUNC, O_APPEND, O_ASYNC, O_DIRECT, O_NOATIME, O_NONBLOCK, O_DSYNC, O_SYNC, O_CLOEXEC
O_CREAT, O_DIRECTORY, O_EXCL, O_NOCTTY, O_NOFOLLOW, O_TMPFILE, O_TRUNC, O_LARGEFILE, O_NDELAY, O_PATH
I couldn't find a simple list telling "X, Y, Z are flags, W, V are modes, etc."
Perhaps they are terms that are used interchangeably, or the mode is a subset of the flags, or...
Related:
Difference between "file pointer", "stream", "file descriptor" and ... "file"? (answers there may be a guide in the present OP, even if not the same).
How to make sense of O_RDONLY = 0?
Difference between "file pointer", "stream", "file descriptor" and ... "file"?
How to get the mode of a file descriptor?
https://www.gnu.org/software/libc/manual/html_node/Access-Modes.html
https://www.gnu.org/software/libc/manual/html_node/File-Status-Flags.html#File-Status-Flags
File descriptors can be duplicated. For example, when a process forks, it gets its own set of FDs that the parent doesn't affect, and the dup syscall can be used to explicitly duplicate individual FDs.
When file descriptors get duplicated, every descriptor has its own set of file descriptor flags, but they'll all share the same file status flags. For example, consider this code:
int fdA = open('/tmp/somefile', O_WRONLY);
int fdB = dup(fdA);
fcntl(fdA, F_SETFD, FD_CLOEXEC);
fcntl(fdA, F_SETFL, O_APPEND);
After running it, fdA will be close-on-exec and in append mode, and fdB will be in append mode but not close-on-exec. This is because close-on-exec is a file descriptor flag and append mode is a file status flag.
The file access mode and file creation flags are passed along with the file status flags when they're supported.
The third parameter to open, also confusingly called mode, is unrelated to everything else discussed so far. If the file is created by the call to open, then that mode is used as the permissions for the new file. Otherwise, it has no effect.
FD_CLOEXEC - file descriptor flag
O_RDONLY - file access mode
O_WRONLY - file access mode
O_RDWR - file access mode
O_CLOEXEC - file creation flag
O_CREAT - file creation flag
O_DIRECTORY - file creation flag
O_EXCL - file creation flag
O_NOCTTY - file creation flag
O_NOFOLLOW - file creation flag
O_TMPFILE - file creation flag
O_TRUNC - file creation flag
The rest of the flags you listed are file status flags.
And one final note: O_CLOEXEC is only relevant for a new FD. For existing FDs, you'll only ever use FD_CLOEXEC.
I will summarize the description by Joseph Sible-Reinstate Monica and add a few remarks on possibly confusing wording across man pages, likely the cause of the OP.
As per headings in http://man7.org/linux/man-pages/man2/fcntl.2.html (as cited in the OP) Flags = File descriptor flags + File status flags.
Remark 1: this usage of File status flags is not consistent with the rest of available information, so it should rather be called something like
Flags = File descriptor flags + Non-FD flags.
The distinction between these two groups of flags is given by Joseph Sible-Reinstate Monica.
As per http://man7.org/linux/man-pages/man2/open.2.html,
Non-FD Flags = Access mode + File creation flags + File status flags
Note that:
The man page does not use the name Non-FD Flags. It simply calls this flags, as the name of the argument in the prototypes listed. But this should not be taken as if, conceptually, these flags encompass all flags since File descriptor flags are not included.
"The distinction between these two groups of flags is that the file creation flags affect the semantics of the open operation itself, while the file status flags affect the semantics of subsequent I/O operations." [ref]
This is the most common usage of File status flags.
This is the basic classification of "entities".
Remark 2: I use quotes since the general use of flags is quite misleading.
Access mode are not flags in the usual sense, and this is clarified in
How to make sense of O_RDONLY = 0?.
Remark 3:
GNU uses a different naming, adding to the confusion.
The translation POSIX.1 <-> GNU is shown below.
Usage of File Status Flags in GNU may be especially confusing.
POSIX.1 GNU
Non-FD Flags* File Status Flags
Access modes Access mode
File creation flags Open-time Flags
File status flags Operating Modes
As for the listings enumerating each category, they are given by Joseph Sible-Reinstate Monica.
GNU also has its own Access modes, File creation flags (Open-time Flags) and File status flags (Operating Modes).
I'm trying to understand what means duplicating a file descriptor after calling fork() and its possible effects on contention.
In "The Linux Programming Interface" 24.2.1 (p517):
When a fork() is performed, the child receives duplicates of all of
the parent's file descriptors. These duplicates are made in the manner
of dup(), which means that corresponding descriptors in the parent and
the child refer to the same open file description.
When I run this same code:
#include <unistd.h>
#include <fcntl.h>
#include <stdio.h>
#include <sys/wait.h>
int main(void) {
char* fl = "/tmp/test_fd";
int fd;
fd = open(fl, O_CREAT|O_TRUNC|O_WRONLY, 0666);
if(!fork()) {
printf("cfd=%d\n", fd);
_exit(0);
} else {
int status;
printf("ffd=%d\n", fd);
wait(&status);
close(fd);
unlink(fl);
}
}
I get the same file descriptor (number?) for both processes: ffd=3 and cfd=3. But when run this code using dup():
#include <unistd.h>
#include <fcntl.h>
#include <stdio.h>
int main(void) {
char* fl = "/tmp/test_fd";
int cfd, ffd;
ffd = open(fl, O_CREAT|O_TRUNC|O_WRONLY, 0666);
cfd = dup(ffd);
printf("ffd=%d\n", ffd);
printf("cfd=%d\n", cfd);
close(ffd);
unlink(fl);
}
I get different file descriptors: ffd=3 and cfd=4.
Then, I have the following questions:
What means fork() creates a copy of the parent's file descriptors?
Is there contention when two processes (father and child) perform an operation like fstat() concurrently on the same file descriptor?
And what about two processes performing fstat() concurrently with two different file descriptors pointing to the same file?
When you see the phrase "duplicate a file descriptor", you need to understand it as "create a new file descriptor which points to the same thing the other one is pointing to".
So when you duplicate fd 3, you get fd 4. The aren't the same number, but they identify the same object.
In the case of fork, you must remember that the meaning of a file descriptor is contained within a process. Lots of processes have a valid fd 3, but they're not all referring to the same object. With fork, you have a duplicate of fd 3 that is also fd 3, but in a different process so those 3's aren't inherently identical; they're identical because fork made a copy.
You can close the fd and open a different file in the child process, and you'll still have two processes in which fd 3 is valid, but they aren't copies of the same thing anymore. Or you could have the child dup the fd 3 to get fd 4, then close fd 3, and then you'd have fd 3 in the parent and fd 4 in the child referring to the same object.
The same number in a different process doesn't mean anything.
Also note that the object referred to by a file descriptor isn't a file. There's something in between a file descriptor and a file, and it's called an open file description. Both fork and dup cause an open open file description to be shared. The main consequence of the sharing is that when the current file position (set by lseek or advanced by read and write) changes, all of the related file descriptors are affected, and when flags (like O_NONBLOCK) are changed, all the related file descriptors are affected.
In contrast if you open the same file twice, you get two file descriptors that refer to the same file, but through different open file descriptions, so they have independent flags and seek position.
fstat being a readonly operation, I don't see what kind of "contention" you're imagining for it.
This is not a code question but an Xcode IDE question.
For those who pride themselves in code analysis, that's good, but in this case, please try to focus on the question in the Title above not the code.
In the Xcode IDE I created a new project and selected a "Command Line Tool" creating ReadAFile.
I then entered some simple code into main.c to read and display the contents of "Data.txt".
I then selected File, New, File, and selected Empty (For an empty document) and named it Data.txt and then I typed out a sentence then saved the file.
In Xcode, when I choose Product, Run, I get the following error:
Error while opening the file.
: No such file or directory
Program ended with exit code: 1
Where do I set the Xcode IDE property so that it knows where my data file is to avoid getting the "No such file or directory" error?
When I enter the very same code into ReadAFile.c and I type out the very same file "Data.txt" at a terminal prompt using vim, save it, and run make ReadAFile, the code executes properly.
#include <stdio.h>
#include <stdlib.h>
#include <string.h>
int main(int argc, const char * argv[]) {
char ch, file_name[25];
FILE *fp;
strcpy(file_name,"Data.txt");
fp = fopen(file_name,"r");
if( fp == NULL ) {
perror("Error while opening the file.\n");
exit(EXIT_FAILURE);
}
printf("The contents of %s file are :\n", file_name);
while( ( ch = fgetc(fp) ) != EOF )
printf("%c",ch);
fclose(fp);
return 0;
}
That's a good question... I have a temporary, work around, answer...
I do respect your request to focusing on the question rather than your code.
As a quick temporary answer, the only answer I have for you at this point is to modify your code, for now, if you are only debugging your code along with your data file. I know hard coding your file locations is a no-no but for debugging purposes the following will get you over this bump in your road. You can try to hard code the directory location along with your data file so that your code can find it. For example, let's say that your Users directory on your Mac is jerryletter, you could copy your Data.txt file to your Users directory ~/jerryletter. Then could modify just one line of your code like the following:
"strcpy(file_name,"/Users/jerryletter/Data.txt");"
DougPan.com
When I open file in mode like this:
file, _ := os.OpenFile("/path/to/my/file", os.O_RDWR|os.O_APPEND, os.FileMode(0666))
file.Seek(start, os.SEEK_SET)
io.CopyN(file, resp.Body, length)
io.CopyN does not respect the position where I sought. It seems it just append to the tail of the file. Instead if I open the file like this:
file, _ := os.OpenFile("/path/to/my/file", os.O_RDWR, os.FileMode(0666))
file.Seek(start, os.SEEK_SET)
io.CopyN(file, resp.Body, length)
It works as I expected. io.CopyN writes to the file from the "start" point I sought. Not sure if this is a feature or a bug?
It's definitely a feature (http://man7.org/linux/man-pages/man2/open.2.html) and it's controlled by underlying OS, not golang runtime.
O_APPEND
The file is opened in append mode. Before each write(2), the
file offset is positioned at the end of the file, as if with
lseek(2). O_APPEND may lead to corrupted files on NFS
filesystems if more than one process appends data to a file at
once. This is because NFS does not support appending to a
file, so the client kernel has to simulate it, which can't be
done without a race condition.
For A.EXE PE file, if the program runs as test mode, I would like to change the process name to "A_TEST.exe".
And if the program runs as safe mode, I want to change to "A_SAFE.exe"
The file name must be same(A.EXE).
Is it possible?
If "process name" is a name which shows Task Manager - you can change it only from ring0.
From ring3 you can only change a default window title.
#include <intrin.h>
PEB* peb = (PEB*)__readfsdword(0x30);
wchar_t newTitle[] = L"NewTitle";
UNICODE_STRING newTitleUStr = {sizeof(newTitle), sizeof(newTitle), newTitle};
peb->ProcessParameters->WindowTitle = newTitleUStr;
As far as I know this isn't possible without changing the file name.