I wrote my own find() function. When I do:
./myown $HOME/Documents test.txt
I get:
/Users/CJ/Documents/test/test.txt
/Users/CJ/Documents/test/test1/test.txt
/Users/CJ/Documents/test/test2/test.txt
However when I do:
./myown $HOME test.txt
I get:
getcwd error
My code for getcwd is here and it is in a helper function:
findit(*directory, *pattern){
...
if(getcwd(cwd, 2048+1) == NULL){
fprintf(stderr, "getcwd error\n");
exit(1);
}
...
}
How can I solve this issue?
EDIT: closedir() solve this issue but there is another issue now. Result is the same when I do : ./myown $HOME/Documents test.txt but when I do the other way I get : stat error
`
struct stat mode;
if(stat(entry->d_name, &mode) == -1){
fprintf(stderr, "stat error\n");
continue;
}`
I didn't use stat error anywhere else in the code.
This can be helpful too, this is how I used open
DIR *dir
dir = opendir(".");
The error is in readdir().
One suggested step in debugging was:
Since getcwd() sets errno when it fails, you should probably report errno, maybe with perror("getcwd"). Although I'm not keen on perror(), it is probably simplest here.
It turns out that the error set was EMFILE Too many open files.
So, now you know what the trouble is. The getcwd() is failing because you have opened a lot of files and not closed enough of them, and it needs some available file descriptors but you've not left it any that it can use.
And, when requested, I elaborated on that with:
You've opened files and/or directories (opening a directory with opendir() usually uses a file descriptor), and you've not closed them. Consequently, the system won't allow you to open any more files — and the getcwd() fails. It probably isn't immediate; your program has probably done some processing before that failure.
The OP observed:
I just saw that I haven't used fclose; give me a second and I will check it if that's it.
Making sure you've used fclose() and closedir() — and plain close() if you've used any file descriptors by calling open() directly — should help. If, however, the call to getcwd() is the very first thing your code is doing, it won't be because you've opened many files (you haven't).
If there are still problems after files have been closed, then you need to take a step back and review the larger context.
For example:
Why is stat() failing after readdir()?
stat() error 'No such file or directory' when file name is returned by readdir()
Related
I am working on a project for a class and we were given a .c file containing the following code:
int fd = -1;
if (fd < 0)
{
fd = open ("my_dev", O_RDWR);
if (fd < 0)
{
perror ("open");
return -1;
}
...
So I understand that it is trying to open a file "my_dev" with read/write permissions, and then is returning the file descriptor on success or a negative value on failure, but what I dont understand is why it is giving me "permission denied" consistently. I tried to use this code:
int des = open("my_dev", O_CREAT | O_RDWR, 0777);
...
close(des)
to open/create the file (this is called before the other block), but this does not work, and yet if I just use this instead:
FILE* file = fopen("my_dev","w+");
fprintf(file,str);
fclose(file);
I can write to the file, meaning I have write permissions. Now normally, I would just use fopen and fprintf for everything, but for this project, we sort of have to use the teacher's .c file which is going to try to use
open()
which is going to give a "permission denied" error which is in turn going to screw up my code.
I guess my question is how fopen and open relate to each other? Everyone seems to be able to recite that open is a system call whereas fopen is a standard lib function, but I cant seem to find a clear answer for how I can create a file with fopen() that can be opened by open() without a "permission denied" error, or how I can create a file with open() which I can then write to, close and open again with open().
In short, how do I create a file in C that I can write to and open later with open(O_RDWR)?
Sorry if this is a little piecey, im super tired.
PS: It should be noted that I am compiling and running on a university computer, so permissions may be "weird" BUT it should be noted that if I create the file with the terminal command "dd" open() will work, and furthermore, I clearly have SOME write permissions since I can indeed write to the file with fopen and fprintf
fopen is a library function that provided by the standard C runtime, it returns a stream and you can call stream functions on it, like fscanf, fprintf, or fread, fwrite.
open is usually a system call on unix-like systems, provided by the operating system kernel, it returns an file descriptor, you can call IO functions with the fd, like read, write.
Generally fopen is implemented using open underline.
If you want to use standard stream functions on a file descriptor, you can use the posix api, fdopen, which takes a fd, and returns a FILE* stream.
I have a daemon process that spawns several threads one of which handles HTTP requests. The handler is intended to return a file located in
resources/html/index.html
I have the following code:
void * read_file_ex(char *file_name, int32_t *data_len) {
FILE *fp;
fp = fopen(file_name, "r");
... // more code to fetch file contents
fclose(fp);
}
void * read_file(char *file_name){
return read_file_ex(file_name, NULL);
}
And in the thread, I call:
read_file("resources/html/index.html");
The code crashes with a "Segmentation Fault" error when a request is made for that file.
When I use GDB to break at fopen, I notice that a NULL is returned and errno is set to 2 (File not found).
Also, when I change the code to use the absolute path of the file:
/usr/sbin/app/resources/html/index.html
then `fopen()' is able to find the index file and everything works fine.
Another thing to mention is that this error happens when run on Debian Linux but not on Ubuntu 12.04 which makes my question look even dumber.
I forgot to add that I am running the program from the same folder that contains the `resources' folder.
If the current directory of the process is not /usr/sbin/app (and it seems a bit unlikely that the current directory would be /usr/bin/app), then the relative pathname won't work. You should always check the return result from fopen() before attempting to use it. There are endless reasons why an open operation can fail even if you're in the correct directory, let alone when there's a chance that you aren't.
Note that if your process uses functions like daemon(), or is run via a daemonize program, the current directory can be changed to / even if you expected it to be somewhere else.
If you need to check the current directory of the process (a process has a single current directory common to all threads), you can use the getcwd() to get the current working directory.
If you need to change directory (again) after daemonizing your process, you can use chdir() to do so. There's also fchdir() which can be used to change back to a directory if you have an open file descriptor for the directory.
I have a situation where I need to get a file name so that I can call the readlink() function. All I have is an integer that was originally stored as a file descriptor via an open() command. Problem is, I don't have access to the function where the open() command executed (if I did, then I wouldn't be posting this). The return value from open() was stored in a struct that I do have access to.
char buf[PATH_MAX];
char tempFD[2]; //file descriptor number of the temporary file created
tempFD[0] = fi->fh + '0';
tempFD[1] = '\0';
char parentFD[2]; //file descriptor number of the original file
parentFD[0] = (fi->fh - 1) + '0';
parentFD[1] = '\0';
if (readlink(tempFD, buf, sizeof(buf)) < 0) {
log_msg("\treadlink() error\n");
perror("readlink() error");
} else
log_msg("readlink() returned '%s' for '%s'\n", buf, tempFD);
This is part of the FUSE file system. The struct is called fi, and the file descriptor is stored in fh, which is of type uint64_t. Because of the way this program executes, I know that the two linked files have file descriptor numbers that are always 1 apart. At least that's my working assumption, which I am trying to verify with this code.
This compiles, but when I run it, my log file shows a readlink error every time. My file descriptors have the correct integer values stored in them, but it's not working.
Does anyone know how I can get the file name from these integer values? Thanks!
If it's acceptable that your code becomes non portable and is tied to being run on a somewhat modern version of Linux, then you can use /proc/<pid>/fd/<fd>. However, I would recommend against adding '0' to the fd as a means to get the string representing the number, because it uses the assumption that fd < 10.
However it would be best if you were able to just pick up the filename instead of relying on /proc. At the very least, you can replace calls to the library's function with a wrapper function using a linker flag. Example of usage is gcc program.c -Wl,-wrap,theFunctionToBeOverriden -o program, all calls to the library function will be linked against __wrap_theFunctionToBeOverriden; the original function is accessible under the name __real_theFunctionToBeOverriden. See this answer https://stackoverflow.com/a/617606/111160 for details.
But, back to the answer not involving linkage rerouting: you can do it something like
char fd_path[100];
snprintf("/proc/%d/fd/%d", sizeof(fd_path), getpid(), fi->fh);
You should now use this /proc/... path (it is a softlink) rather than using the path it links to.
You can call readlink to find the actual path in the filesystem. However, doing so introduces a security vulnerability and I suggest against using the path readlink returns.
When the file the descriptor points at is deleted,unlinked, then you can still access it through the /proc/... path. However, when you readlink on it, you get the original pathname (appended with a ' (deleted)' text).
If your file was /tmp/a.txt and it gets deleted, readlink on the /proc/... path returns /tmp/a.txt (deleted). If this path exists, you will be able to access it!, while you wanted to access a different file (/tmp/a.txt). An attacker may be able to provide hostile contents in the /tmp/a.txt (deleted) file.
On the other hand, if you just access the file through the /proc/... path, you will access the correct (unlinked but still alive) file, even if the path claims to be a link to something else.
I am trying to make a system call in my source code as follows.
int file;
file = open(argv[index], O_RDONLY);
Where the command line arguement is a path to a binary file in my filesystem. But this call throws me an EINVAL error. I have checked the existence of file and the required permissions to access it.
Any suggestions on what circumstances the EINVAL error will be thrown out.
The official documentation suggests that this is because your implementation of open() does not support synchronized IO for the file you are trying to open.
Cause of failure:
There were two processes say (process-1 and process-2) that were executing in close sequel and was trying to open this binary file. Since my system (embedded device) will crash after this open call, the debugs splitted out weren't proper and it made me to suspect the process-1. But the actual culprit is process-2 who was opening the binary with O_RDWR flag. But my file system (network mount) was mounted as "read only file system".
Points to be taken care:
Refining the perror prints it should be the right cause of the problem as "Read Only File System". So my initial perror description must be a uncleared value of any of the previous erroneous call. One learning here is to use perror with care, so as avoid analysing misleading error message.
Possible circumstances the EINVAL error will be thrown out:
The open call will show an EINVAL if we use O_SYNC (or) related flags for the file which we are not supposed to use. I conclude this based on the documentation as previously mentioned by Rafe.
If you are sure that argv[index] actually contains the filename and that O_RDONLY hasn't been overridden somehow (O_RDONLY should equal 0), check your system log via the dmesg command and make sure that nothing funky has happened in-kernel.
I am trying to make a simple program that handles files and directories, but I have two major problems:
how can I check whether a file or directory exists or not, and
how do I know if it is a file, directory, symbolic link, device, named pipe etc.? Mainly file and directories matter for now, but I'd like to know the others too.
EDIT: Too all of those who are suggesting to use stat() or a similar function, I have already looked into that, and while it might answer my first question, I can't figure out how it would answer the second...
Since you're inquiring about named pipes/symlinks etc, you're probably on *nix, so use the
lstat() function
struct stat info;
if(lstat(name,&info) != 0) {
if(errno == ENOENT) {
// doesn't exist
} else if(errno == EACCES) {
// we don't have permission to know if
// the path/file exists.. impossible to tell
} else {
//general error handling
}
return;
}
//so, it exists.
if(S_ISDIR(info.st_mode)) {
//it's a directory
} else if(S_ISFIFO(info.st_mode)) {
//it's a named pipe
} else if(....) {
}
Se docs here for the S_ISXXX macros you can use.
The stat() function should give you everything you are looking for (or more specifically lstat() since stat() will follow the link).
Use stat (or if you wish to get information about a symbolic link instead of following it and getting information about the destination, lstat)
NAME
stat - get file status
SYNOPSIS
#include <sys/stat.h>
int stat(const char *restrict path, struct stat *restrict buf);
DESCRIPTION
The stat() function shall obtain information about the named file and write it to the area pointed to by the buf argument. The path argument points to a pathname naming a file. Read, write, or execute permission of the named file is not required. An implementation that provides additional or alternate file access control mechanisms may, under implementation-defined conditions, cause stat() to fail. In particular, the system may deny the existence of the file specified by path.
If the named file is a symbolic link, the stat() function shall continue pathname resolution using the contents of the symbolic link, and shall return information pertaining to the resulting file if the file exists.
The buf argument is a pointer to a stat structure, as defined in the header, into which information is placed concerning the file.