live update on file /proc/<pid>/status when open - c

I am trying to read information from the /proc/<pid>/status file (to get the memory used).
To do this, I open the file in read mode:
file = fopen("/proc/self/status", "r");
After this step, to get the memory, I read the line that starts with "VmRSS".
My problem is this:
Each time I read this line, it's the same value, even if the file has changed.
I am doing this to get real-time memory usage of my program. So I call fopen() 1 time,
and then I call fseek() to go to the beginning of my file when I need updated information.
char line[128];
fseek(file, 0, SEEK_SET);
while (fgets(line, 128, file) != NULL)
{
//...
}
But, the file is not updated, unless I reopen it. I don't want to reopen it for performance reasons.
I tried to change "r" to "r+" (to have a "Open a file for update", according to the documentation of fopen()), but fopen returns NULL in this case.
So my question:
Do you have any idea on how my program can open a file and see changes from made by another programme (here the kernel) using only one call to fopen()?
Note :
I use Ubuntu 12.04

You need to reopen the file To avoid race conditions,
proc is a file system in memeory and most /proc content are being fixed on open.

Maybe you can open the /proc/<pid>/status file with open but not fopen.
int fd = open('/proc/<pid>/status', O_RDONLY, MYF(0));
// read
seek(fd, 0L, MY_SEEK_SET, MYF(0));
// read

Related

How can C read content that is newly inserted into a file?

I want to first write something to a file, then use fgets to read it. But I want it to work without close it and switch file open mode between read and write,
I have tried r+ and w+ for file open. For r+ it is able to read original content but fail to read newly inserted content. For w+ it does not read anything I think that's because w+ clear the original content.
I currently found no way to read the newly inserted content of a file before close and switch file open mode, although with fflush new content is already written to a file and can be viewed externally.
Here is a simple code snippet for testing.
#include <stdio.h>
int main()
{
FILE *fp = NULL;
char line[256];
int status;
/*input by user*/
scanf("%s", line);
/*write to a file*/
fp = fopen("f5.txt", "w+");
fprintf(fp, "%s", line);
fflush(fp); /*flush buffer*/
/*read it*/
char lineRead[256];
while (fgets(lineRead, 5, fp) != NULL) {
puts(lineRead);
}
fclose(fp);
}
You might use not only fflush, but also rewind, fseek, ftell (or even fgetpos & fsetpos)
Beware that any standard IO function can fail, and you should check that.
On Linux, some files (e.g. fifo(7)) are not seekable.
Perhaps you want some higher level way of storing persistent data on the disk. Did you consider using some library for indexed files (like gdbm) or for databases (like sqlite)? Or even use a full fledged database, like with some RDBMS (e.g. PostGreSQL or MySQL or MariaDB which are free software), or some NoSQL thing like e.g. MongoDB ?
There is no way to insert a sequence of bytes in the middle of some file or to delete, i.e. remove, a sequence of bytes inside a file. This is a fundamental limitation of file systems on most current operating systems (and on all usual ones like Linux & Windows & Android & MacOSX). You generally should copy that file (by chunks) into some other one (and libraries like gdbm or sqlite don't do that, they either append some data to a file at its end or rewrite some bytes inside the file; they might also truncate a file).
In particular, if you want to programmatically insert some line in the middle of some small text file, you usually should read the file entirely in some appropriate data structure, modify that data structure in memory, then dump that data structure into the (overwritten) file.
You need to use fseek() to return to the beginning of the file before trying to read it.

Reopen a file descriptor with another access?

Assume the OS is linux. Suppose I opened a file for write and get a file descriptor fdw. Is it possible to get another file descriptor fdr, with read-only access to the file without calling open again? The reason I don't want to call open is the underlying file may have been moved or even unlinked in the file system by other processes, so re-use the same file name is not reliable against such actions. So my question is: is there anyway to open a file descriptor with different access right if given only a file descriptor? dup or dup2 doesn't change the access right, I think.
Yes! The trick is to access the deleted file via /proc/self/fd/n. It’s a linux-only trick, as far as I know.
Run this program:
#include <stdio.h>
#include <stdlib.h>
#include <unistd.h>
int main() {
FILE* out_file;
FILE* in_file;
char* dev_fd_path;
char buffer[128];
/* Write “hi!” to test.txt */
out_file = fopen("test.txt", "w");
fputs("hi!\n", out_file);
fflush(out_file);
/* Delete the file */
unlink("test.txt");
/* Verify that the file is gone */
system("ls test.txt");
/* Reopen the filehandle in read-mode from /proc */
asprintf(&dev_fd_path, "/proc/self/fd/%d", fileno(out_file));
in_file = fopen(dev_fd_path, "r");
if (!in_file) {
perror("in_file is NULL");
exit(1);
}
printf("%s", fgets(buffer, sizeof(buffer), in_file));
return 0;
}
It writes some text to a file, deletes it, but keeps the file descriptor open and and then reopens it via a different route. Files aren’t actually deleted until the last process holding the last file descriptor closes it, and until then, you can get at the file contents via /proc.
Thanks to my old boss Anatoly for teaching me this trick when I deleted some important files that were fortunately still being appended to by another process!
No, the fcntl call will not let you set the read/write bits on an open file descriptor and the only way to get a new file descriptor from an existing one is by using the duplicate functionality. The calls to dup/dup2/dup3 (and fcntl) do not allow you to change the file access mode.
NOTE: this is true for Linux, but not true for other Unixes in general. In HP-UX, for example, [see (1) and (2)] you are able to change the read/write bits with fcntl using F_SETFL on an open file descriptor. Since file descriptors created by dup share the same status flags, however, changing the access mode for one will necessarily change it for the other.

clear/truncate file in C when already open in "r+" mode

My code currently looks something like this (these steps splitted into multiple functions):
/* open file */
FILE *file = fopen(filename, "r+");
if(!file) {
/* read the file */
/* modify the data */
/* truncate file (how does this work?)*/
/* write new data into file */
/* close file */
fclose(file);
}
I know I could open the file with in "w" mode, but I don't want to do this in this case. I know there is a function ftruncate in unistd.h/sys/types.h, but I don't want to use these functions my code should be highly portable (on windows too).
Is there a possibility to clear a file without closing/reopen it?
With standard C, the only way is to reopen the file in "w+" mode every time you need to truncate. You can use freopen() for this. "w+" will continue to allow reading from it, so there's no need to close and reopen yet again in "r+" mode. The semantics of "w+" are:
Open for reading and writing. The file is created if it does not exist, otherwise it is truncated. The stream is positioned at the beginning of the file.
(Taken from the fopen(3) man page.)
You can pass a NULL pointer as the filename parameter when using freopen():
my_file = freopen(NULL, "w+", my_file);
If you don't need to read from the file anymore at all, when "w" mode will also do just fine.
You can write a function something like this:(pseudo code)
if(this is linux box)
use truncate()
else if (this is windows box)
use _chsize_s()
This is the most straightforward solution for your requirement.
Refer: man truncate and _chsize_s at msdn.microsoft.com
and include necessary header files too.

Do I need to fflush or close a file before calling stat on it?

After opening a file for writing:
FILE *file = fopen("./file", "w");
Can I assume the file was created immediately? Is it safe to call:
stat( "./file", info);
Or should I better:
fflush(file);
or
fclose(file);
beforehand?
Edit: Assume non NULL file after fopen call
The fopen manual page says:
If mode is w, wb, a, ab, w+, wb+, w+b, a+, ab+, or a+b, and the file
did not previously exist, upon successful completion, the fopen()
function shall mark for update the st_atime, st_ctime, and st_mtime
fields of the file and the st_ctime and st_mtime fields of the parent
directory.
So I think it is safe to stat on the file just after a successful fopen call.
Yes, logically we could do it. As opening a file for writing in read-only filesystem fails. This indicates that fopen()/open() does required checks. Other way to confirm is this by opening file with x similar to O_EXCL flag of open().
If the call to fopen is successful then it means that the file is created. The file may not be committed ( flushed ) to the disk though. But you need not worry about this as the next call to stat will fetch the file from the kernel buffer.
So an fflush or an fclose is not required in this particular case.
The few times where in you need to scratch your head about flushing to disk is when there is a probability of a system crash. In this case if you haven't committed data completely to the disk using something like fsync, then there might be probable data loss upon next system restart.

C Programming fopen() while opening a file

I've been wondering about this one. Most books I've read shows that when you open a file and you found that the file is not existing, you should put an error that there's no such file then exit the system...
FILE *stream = NULL;
stream = fopen("student.txt", "rt");
if (stream==NULL) {
printf(“Cannot open input file\n”);
exit(1);
else {printf("\nReading the student list directory. Wait a moment please...");
But I thought that instead of doing that.. why not automatically create a new one when you found that the file you are opening is not existing. Even if you will not be writing on the file upon using the program (but will use it next time). I'm not sure if this is efficient or not. I'm just new here and have no programming experience whatsoever so I'm asking your opinion what are the advantages and disadvantages of creating a file upon trying to open it instead of exiting the system as usually being exampled on the books.
FILE *stream = NULL;
stream = fopen("student.txt", "rt");
if (stream == NULL) stream = fopen("student.txt", "wt");
else {
printf("\nReading the student list directory. Wait a moment please...");
Your opinion will be highly appreciated. Thank you.
Because from your example, it seems like it's an input file, if it doesn't exist, no point creating it.
For example if the program is supposed to open a file, then count how many vowels in it, then I don't see much sense of creating the file if it doesn't exist.
my $0.02 worth.
Argument mode:
``r'' Open text file for reading.
``r+'' Open for reading and writing.
``w'' Truncate file to zero length or create text file for writing.
``w+'' Open for reading and writing. The file is created if it does not
exist, otherwise it is truncated.
``a'' Open for writing. The file is created if it does not exist.
``a+'' Open for reading and writing. The file is created if it does not
exist.
Your question is a simple case. Read above description, when you call fopen(), you should decide which mode shall be used. Please consider why a file is not created for "r" and "r+", and why a file is truncated for "w" and "w+", etc. All of these are reasonable designs.
If your program expects a file to exist and it doesn't, then creating one yourself doesn't make much sense, since it's going to be empty.
If OTOH, your program is OK with a file not existing and knows how to populate one from scratch, then it's perfectly fine to do so.
Either is fine as long as it makes sense for your program. Don't worry about efficiency here -- it's negligible. Worry about correctness first.
You may not have permission to create/write to a file in the directory that the user chooses. You will have to handle that error condition.

Resources