I'm just trying to recover a file in C on an HFS+ formatted Volumn. According to
man undelete
NAME
undelete -- attempt to recover a deleted file
LIBRARY
Standard C Library (libc, -lc)
SYNOPSIS
#include
int
undelete(const char *path);
DESCRIPTION
The undelete() system call attempts to recover the deleted file named
by path. Currently, this works only when the named object is a
whiteout in a union file system. The system call removes the whiteout
causing any objects in a lower layer of the union stack to become
visible once more.
Eventually, the undelete() functionality may be expanded to other file
systems able to recover deleted files such as the log-structured file
system.
RETURN VALUES
The undelete() function returns the value 0 if successful; otherwise
the value -1 is returned and the global variable errno is set to
indicate the error.
so the Program is simple:
The current directory (pwd) is /Users/Leo/Desktop/ and I'm on a Mac 10.7.2 with HFS+ Filesystem.
#include <unistd.h>
int main()
{
char a="/Users/Leo/Desktop/test/a.out";//I delete a.out using rm for testing
const char* pa=&a;
return undelete(pa);
}
But when I run the program, I got shell returned 255.
Any idea? Thanks
undelete is failing. To find out why, check errno. For example:
#include <unistd.h>
int main( int argc, char **argv )
{
char *path = argc > 1 ? argv[ 1 ] : "a.out";
if( undelete(path))
perror( path );
return 0;
}
Although it appears your problem is that you have a char instead of a char pointer.
You should have gotten a compiler warning.
First, you need to check the return value and evaluate it. If it is -1 then print an error message, for example with perror or by formatting an error message and using strerror(errno).
But you've also got a major bug before you even attempt to call undelete:
char a="/Users/Leo/Desktop/test/a.out";
const char* pa=&a;
This will first assign a value (the pointer to your string) to a char, a single byte value. The compiler even warns about that with warning: initialization makes integer from pointer without a cast. In my case, a then had the value D/0x44, but it could have been anything. You then store the pointer to that single byte in pa. What you want instead is:
const char* pa="/Users/Leo/Desktop/test/a.out";
Related
I have this code, note that it is shortened down. The problem is if the file exists
it still overwrites it. Been 30 years since I did any programming so bear with me. Thanks!
FILE *openFil(FILE *open, char namn[]);
int main(int argc, const char * argv[])
{
FILE *openFil(FILE *open, char namn[]);
FILE *anmal =NULL;
char filNamn[] = "ANMAL.DAT";
postTypAnm pAnm;
anmal = openFil(anmal, filNamn);
}
FILE *openFil(FILE *pointer, char name[])
{
if ((pointer =fopen(name, "r+b"))== NULL)
if ((pointer =fopen(name, "w+b"))== NULL)
{
/* It Enters here as well, but it should not do that or????? */
printf("error\n");
exit(0);
}
return pointer;
}
If you're using the C11 standard you can use the "x" argument to specify that if the file exists the fopen() function will fail.
For reference: http://www.cplusplus.com/reference/cstdio/fopen/
Here's a working example.
#include <errno.h>
#include <stdio.h>
#include <stdbool.h>
#include <stdlib.h>
bool openFile(FILE **ptr,
const char *fileName);
int main(int argc, const char * argv[]) {
FILE *anmal = NULL;
const char *fileName = "ANMAL.DAT";
if(!openFile(&anmal, fileName)) {
exit(EXIT_FAILURE);
}
}
bool openFile(FILE **ptr,
const char *fileName)
{
*ptr = fopen(fileName, "w+bx");
if(!*ptr) {
perror("Error opening file: ");
return false;
}
return true;
}
This is using the x extension in GNU C to test whether the file exists.
As other people have pointed out, there are numerous problems in your original code.
You've redeclared the function prototype for openFil within main.
In openFil there's no point in both accepting the FILE pointer as
a parameter and overwriting it with the return value. Especially if
you're expecting to input a NULL pointer and use the function to
initialise it. Either use a pointer-to-pointer as a parameter so you
can modify the pointer within the function, or ignore it completely
and set its value with the function's return value. Not both.
You're not actually testing for whether the file exists at all. According to the manual pages for fopen (man fopen) neither of the flags you used in opening the file (r+ and w+) care whether the file exists. r+ opens for reading/writing and always positions the stream at the beginning of the file. w+ opens for reading/writing, truncating the file if it exists already. This explains why you didn't get the effect you intended.
1.
"It Enters here as well, but it should not do that or?????"
No, It shouldn´t. If both pointers are NULL the opening of the streams to ANMAL.DAT were not successful, neither in w+b nor in r+b mode. Proof if the file really exist in the directory of the executable. Else try to use the entire path from the root directory to the file.
"The problem is if the file exists it still overwrites it."
Why do you know that the file is really overwritten in a proper manner?
Since if ((pointer =fopen(name, "r+b")) == NULL) and if ((pointer = fopen(name, "w+b"))== NULL) both fail, it seems that the ANMAL.DAT does not exist where fopen() searches for it or otherwise an error occurs when trying to open it (maybe has incorrect format or is corrupted?).
Place perror(name) in the error routine to check if errno was set to indicate an error at name.
2.
In the error routine: exit(0) is not correct if an error has happened. Use exit(EXIT_FAILURE).
Side note:
You have another prototype for the function openFil-> FILE *openFil(FILE *open, char namn[]); inside of main, which is redundant.
Also the identifier of the second parameter is different in the prototype before main to the identifier at the definition of openFil, namn in comparison to name.
I have a Hex file whose contents are like below:
0x14000800
0x52100000
0xD503201F
0xD503201F
0x0030A308
0x0032D138
0x00000000
0x00000000
0x00000000
0x00000000
I need to open and read this file. Below is my code:
#include <stdio.h>
#include <stdlib.h>
int main(void)
{
char ch, boot_rom_golden[16];
FILE *myFile = NULL;
myFile = fopen("/prj/vlsi/tests/boot_rom_fail/src/apps_proc0/sm6140_rom.a52100000_ROM_FULL.hex", "r");
if (myFile == NULL) {
printf("Error Reading File\n");
exit(0);
}
while ((ch = fgetc(myFile)) != EOF) {
printf("%x \n", ch);
}
I have two questions:
My understanding is if the file does not exist in the above mentioned path, then fopen should return a NULL. Observation is : even if the file does not exist in the above path (/prj/vlsi/....) , fopen is returning some value and then it goes to while loop trying to print the content. Why is this happening? My main.c and the hex file are residing in the same path. But still I tried giving the complete path which also gave the same results (i.e. even if file does not exist it is returning a non zero pointer value)
When the code executes while loop, it prints "FF" indefinitely. It should be because of reason stated above.
Please help to know the issue and how to debug these kind of issues ?
Use an int instead of a char for ch
1) Because fgetc returns an int
The C library function int fgetc(FILE *stream) gets the next character
(an unsigned char) from the specified stream and advances the position
indicator for the stream.
2) Because EOF can be defined as some number not representable by char
Same for boot_rom_golden
When I compile and run your code on my system it behaves as you would expect: myFile becomes a null pointer and the null test causes an early exit. On your machine, myFile == NULL is not true, and the early exit does not occur.
I deduce that either the code you are actually executing is not the same as the code you posted, or there is something going on in your environment that is different from mine.
Can you trace through this line by line?
Are you certain that the file named does not exist on your system at the moment this is being executed?
Perhaps there is truncation occurring? Try a short path and short filename.
Try an absolute filepath rather than a relative one.
Null is likely a macro -- perhaps it's not what you think? Try if(myFile) as an alternate.
If not resolved, post more info about your system, and tell us what myFile is when your system does not think it's equal to NULL.
For my assignment I have to create a program similar to the -wc unix command which counts words, lines, etc.
I have to read in flags and read in a text file.
I've set up all the flags and now I'm trying to read in a text file. I don't think I'm doing this right.
void readInFile(char** argv, int arg)
{
FILE *myFile;
char c;
myFile = fopen(argv[arg], "r");
if(!myfile)
{
printf("%s not found!", argv[arg]);
exit(EXIT_FAILURE);
}
}
in my main I call the function readInFile() and pass 2 arguments. Argv and the element where the file should be. So assume this to be correct.
I need help with actually opening up the file. I feel like my fopen() is wrong. I'm new to reading/writing files in C. Thanks alot!
I'm going to give you some general advice here.
Usually functions should do a single job. In this case, you are writing a function to read in a single file. So, don't pass a pointer to all the command-line arguments; pass in a single read-only pointer to the name of the file to open. Then in main() select the correct argument and pass that as the argument.
void readInFile(char const *filename)
Now, if this function will be reading in the file and doing nothing else, it needs to return the data somehow. But if this function will be doing the equivalent of wc, maybe it will read the file and print stuff, not return any data to the main() function. Then maybe the name should be improved:
void wordcount(char const *filename)
The actual call to fopen() looks fine to me.
You check for error, and then call exit() immediately. That's one way to do it. Another way to do it is to return an error code from your function, and have the caller (the main() function) check for failure, and handle the error there.
int wordcount(char const *filename)
{
// ... do stuff
if (failed)
return 1; // return nonzero error code on failure
// ... do more stuff
return 0; // success code
}
int main(int argc, char const **argv)
{
char const *filename;
int result;
filename = argv[1];
result = wordcount(filename);
if (result)
{
fprintf(stderr, "unable to open file '%s'\n", filename, result);
exit(result);
}
return 0;
}
For a program this simple, it doesn't matter much. But once you start building larger systems in software, you will be happier if your functions work well together, and part of that is making functions that return error codes rather than terminating your whole program on any error.
Why am I using 0 for the success code, and non-zero for failure? It's a common way to do it. It's easy to test for non-zero, like if (result) and there are many non-zero codes but only one zero, so you can return many different kinds of errors, but there is only one value needed for "success".
Note that instead of calling exit() from main(), you can just use the return statement. When you return 0 from main(), that signals success, and a non-zero value indicates an error. So you could just use return result; from main() if you like.
In my dummy code, I'm just returning 1 as the error code. But actually, when you call fopen() it returns an error code to you, in a global variable called errno. Probably a better option is to make your function return the actual error code as specified in errno. You could even modify the print statement in the main() function print the errno code, or use the strerror() function to turn that error code into a human-readable message.
Your call to fopen is correct, assuming that argv[arg] is a valid string which refers to a file that exists on the filesystem.
There is a small typo in the program snippet. if(!myfile) should prpbably be if(!myFile). With this change, I presume the code should work. Can you please elaborate the error faced by you?
P.S: I tried your program and it seems to work!
I want to move the contents of one directory to another. I specify the source and destination directories via command line arguments. Here's the code:
#include <stdlib.h>
#include <stdio.h>
void move_dir(FILE *src, FILE *dest) {
int c = getc(src);
while(getc(src)!=EOF) {
putc(c,dest);
}
}
int main(int argc, char* argv[])
{
FILE *src=fopen(argv[1]);
FILE *dest=fopen(argv[2]);
while(--argc>0) {
if(src!=NULL && dest!=NULL) {
move_dir(src,dest);
}
}
fclose(src);
fclose(dest);
return 0;
}
For example:
./a.out /Folder1/Folder2/Source /Folder1
This will move the folder called Source inside of Folder1. However when I execute this code it doesn't work. It compiles just fine with g++ and no errors when running but it just doesn't move anything at all. Any ideas on what could be wrong?
Edit: This is referring to the original post, which read FILE * src = opendir( argv[1] );.
The function opendir() returns a DIR *, which is quite different from a FILE * (and cannot be used as a parameter to getc() / putc().
You have to read directory entries from that DIR * using readdir(), which will yield a filename, then copying that file using that information.
Edit: This is referring to the updated post.
You don't use file functions (fopen(), getc() etc.) on directories. The way to go is opendir() followed by readdir(), then acting on the yielded filenames.
I don't really know why fopen() on a directory actually returns a non-null pointer. Personally, I consider this a design flaw, as the operations possible on FILE * are not defined for directories. I would stay well clear of this construct.
Generally speaking, you should read the documentation (man page) of the functions you are using, not (wrongly) assuming things about them. And while you are at it, check return values, too - they might tell you why things don't work as expected.
I have a program where I need to set the permissions of a file (say /home/hello.t) using chmod and I have to read the permissions to be set from a file. For this I first read the permissions into a character array and then try to modify the permissions of the file. But I see that permissions are set in a weird manner.
A sample program I have written:
main()
{
char mode[4]="0777";
char buf[100]="/home/hello.t";
int i;
i = atoi(mode);
if (chmod (buf,i) < 0)
printf("error in chmod");
}
I see that the permissions of the file are not set to 777. Can you please help me out on how to set the permissions of the file after reading the same from a character array.
The atoi() function only translates decimal, not octal.
For octal conversion, use strtol() (or, as Chris Jester-Young points out, strtoul() - though the valid sizes of file permission modes for Unix all fit within 16 bits, and so will never produce a negative long anyway) with either 0 or 8 as the base. Actually, in this context, specifying 8 is best. It allows people to write 777 and get the correct octal value. With a base of 0 specified, the string 777 is decimal (again).
Additionally:
Do not use 'implicit int' return type for main(); be explicit as required by C99 and use int main(void) or int main(int argc, char **argv).
Do not play with chopping trailing nulls off your string.
char mode[4] = "0777";
This prevents C from storing a terminal null - bad! Use:
char mode[] = "0777";
This allocates the 5 bytes needed to store the string with a null terminator.
Report errors on stderr, not stdout.
Report errors with a newline at the end.
It is good practice to include the program name and file name in the error message, and also (as CJY pointed out) to include the system error number and the corresponding string in the output. That requires the <string.h> header (for strerror()) and <errno.h> for errno. Additionally, the exit status of the program should indicate failure when the chmod() operation fails.
Putting all the changes together yields:
#include <stdio.h>
#include <stdlib.h>
#include <string.h>
#include <errno.h>
#include <sys/stat.h>
int main(int argc, char **argv)
{
char mode[] = "0777";
char buf[100] = "/home/hello.t";
int i;
i = strtol(mode, 0, 8);
if (chmod (buf,i) < 0)
{
fprintf(stderr, "%s: error in chmod(%s, %s) - %d (%s)\n",
argv[0], buf, mode, errno, strerror(errno));
exit(1);
}
return(0);
}
Be careful with errno; it can change when functions are called. It is safe enough here, but in many scenarios, it is a good idea to capture errno into a local variable and use the local variable in printing operations, etc.
Note too that the code does no error checking on the result of strtol(). In this context, it is safe enough; if the user supplied the value, it would be a bad idea to trust them to get it right.
One last comment: generally, you should not use 777 permission on files (or directories). For files, it means that you don't mind who gets to modify your executable program, or how. This is usually not the case; you do care (or should care) who modifies your programs. Generally, don't make data files executable at all; when files are executable, do not give public write access and look askance at group write access. For directories, public write permission means you do not mind who removes any of the files in the directory (or adds files). Again, occasionally, this may be the correct permission setting to use, but it is very seldom correct. (For directories, it is usually a good idea to use the 'sticky bit' too: 1777 permission is what is typically used on /tmp, for example - but not on MacOS X.)