I want to truncate the file something like setsizeof() with FILE *
I'm developing vs 2003 windows
#include <unistd.h> there's no such lib
how can I do it freopen() truncates all the data vut doesn't write- getting EINVAL error
some help?????
_chsize function does the job better it get fd ans size to change to
There are a number (roughly 20) of header files in the C standard and unistd is not one of them (it's a POSIX/UNIX95/UNIX98 header). So there's no requirement for a vendor to provide it. Neither C89 nor C99 have unistd as one the the mandated header files.
The easiest way to truncate a file is to reopen it in write mode (assuming you have the file name).
fclose (fh);
fh = fopen ("file_name", "w");
If all you have is the file handle, you need to use freopen(). You will only get EINVAL if the mode is incorrect. You cannot change the mode except accoording to the following table:
r -> r
w a -> a w
r+ w+ a+ -> any mode
See man freopen for further details.
Related
I want:
file to be created if it does not exist, not overwritten if it does.
to read and write and fseek where ever I want
and I can not find out valid mode — "w+", "rw" "rwb+" "r+b" "w+b" "a+" or what?
The basic level 'open' that performs well is:
int fd =open("fname", O_RDWR | O_CREAT, 0666);
but I would like to know fopen alternative.
Every mode letters [w, r, a, +] combination I tried will either overwrite contents, or fseek-fwrite not write where it should. "a+" will always append no matter what fseek sets... "rw+" works ok, but does not create nonexistent file ...etc.
Update: to clarify why for example "a+" is NOT a solution:
#include <stdio.h>
int main()
{ FILE *fp =fopen("aaa.txt", "a+");
fwrite("aaaaaaaaaaaaaaaaaaa", 1, 10, fp);
fseek(fp, 5, SEEK_SET);
fwrite("AAA", 1, 3, fp);
fclose(fp);
return 0;
}
runned with: $ rm aaa.txt; gcc test.c && ./a.out && cat aaa.txt && echo .
produces wrong result: aaaaaaaaaaAAA.
result should be: aaaaaAAAaa
Update2: summary... minimal functions that i end up with:
FILE *fopenrwc(char*n) {FILE*f=fopen(n,"a");if(f)fclose(f),f=fopen(n,"r+");return f;}
or:
FILE *fopenrwc(char*n) {return fdopen(open(n,O_RDWR|O_CREAT,0666),"r+");}
If you review the manual page for fopen(), none of the standard open mode strings meets your requirements.
If you're on a sufficiently POSIX-like machine to be able to use open(), don't underestimate the benefits of fdopen() which would allow you to use open() with the options you showed and then create a file stream to use that file.
Note that "rw+" is not a valid mode. If you're (un)lucky, it gets treated as r+.
If you can't use fdopen() for some reason, you may be best off trying r+ and if that fails using w+; that opens a small window of vulnerability where someone might create a file that you then clobber with the w+ option — or creates a symlink so you end up creating a file where you didn't intend to do so.
This is the way it used to be necessary to work with open(); originally, you called open() — in the days before there was an O_CREAT — and if that failed, then you used creat() instead. That's a long time ago, though — see 'UNIX Programming' in 7th Edition UNIX Programmer's Manual Vol 2.
In general, testing with access() doesn't help. It leaves open a window of vulnerability because there is a TOCTOU — Time of Check, Time of Use — gap between the use of access() and open() (or fopen()). This is also the trouble with open() and creat(), or two calls to fopen().
If you want the finer controls, such as O_EXCL, or specialized properties such as O_DSYNC or O_NOCTTY, or even control over the permissions on the created file other than the default as modified by umask(), then open() plus fdopen() is practically the only way to go.
There is no direct way to meet your requirement with a simple fopen. IMHO, you best choice is to first use a low level open to create the file, and then use a fdopen (as suggested by Jonathan Leffler) to get a FILE * that can then be used with all the C library IO functions:
int fd =open("fname", O_RDWR | O_CREAT, 0666);
FILE *fp = fdopen(fd, "r+");
/* Ok, you can do what you want with fp */
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'm working on improving my C programming knowledge, but I am having trouble understanding the man pages for the following Unix system calls:
open
create
close
unlink
read
write
lseek
The man pages for each of these are, for lack of a better term, completely confusing and unintelligible. For example, here is the man page for open:
"Given a pathname for a file, open() returns a file descriptor, a small, nonnegative integer for use in subsequent system calls (read(2), write(2), lseek(2), fcntl(2), etc.). The file descriptor returned by a successful call will be the lowest-numbered file descriptor not currently open for the process.
By default, the new file descriptor is set to remain open across an execve(2) (i.e., the FD_CLOEXEC file descriptor flag described in fcntl(2) is initially disabled; the O_CLOEXEC flag, described below, can be used to change this default). The file offset is set to the beginning of the file (see lseek(2)).
A call to open() creates a new open file description, an entry in the system-wide table of open files. This entry records the file offset and the file status flags (modifiable via the fcntl(2) F_SETFL operation). A file descriptor is a reference to one of these entries; this reference is unaffected if pathname is subsequently removed or modified to refer to a different file. The new open file description is initially not shared with any other process, but sharing may arise via fork(2)."
I have no idea what this all means. From my understanding, if open returns a negative integer, an error occurred, and if it returns a positive integer, then that integer can be used in further system calls (???). That is, unfortunately, basically the extent of my knowledge and what I can attempt to parse from the man page. I need some help.
What does it mean that it "returns the lowest-numbered file descriptor not currently open for the process"? What process is it referring to? Why is it the lowest-numbered file descriptor, and why does this matter/how would I use this? I hate to sound like an idiot but I honestly have no clue what it's talking about.
Let's take an example. Let's say I wanted to create a new file in a directory, and open up a file from another directory, and copy the file I opened into the file I created, while checking for errors along the way. This is my attempt:
#include <stdio.h>
#include <unistd.h>
#include <fcntl.h>
int main()
{
int XYZ = creat("XYZ.doc", 0 );
if (XYZ < 0)
printf("file creating error");
int file = open("/usr/.../xx.xx", 0);
if(file < 0)
printf("file opening error");
}
How would I copy the file that I opened into the file that I created? That should be easy. But what if I wanted to copy the file that I opened in reverse to the file that I created? (Maybe that example will illuminate how to use the file offset stuff mentioned in the man page, which I don't currently understand...)
I would like to edit this post to write a layman's terms description next to each of these system calls, thus creating a good online resource for people to study from. Also, if anyone has any good references for these system calls in C, that would be much appreciated as well.
Error checking left out for simplicity sake:
char data[1024]; /* size of this chosen more or less on a whim */
ssize_t n;
while ((n = read(file, data, sizeof(data))) > 0) {
write(XYZ, data, n);
}
close(file);
close(XYZ);
It looks like this question is pretty simple but I can't find the clear solution for copying files in C without platform dependency.
I used a system() call in my open source project for creating a directory, copying files and run external programs. It works very well in Mac OS X and other Unix-ish systems, but it fails on Windows. The problem was:
system( "cp a.txt destination/b.txt" );
Windows uses backslashes for path separator. (vs slashes in Unix-ish)
Windows uses 'copy' for the internal copy command. (vs cp in Unix-ish)
How can I write a copying code without dependency?
( Actually, I wrote macros to solve this problems, but it's not cool. http://code.google.com/p/npk/source/browse/trunk/npk/cli/tests/testutil.h, L22-56 )
The system() function is a lot more trouble than it's worth; it invokes the shell in a seperate proccess, and should usually be avoided.
Instead fopen() a.txt and dest/b.text, and use getc()/putc() to do the copying (because the standard library is more likely to do page-aligned buffering than you)
FILE *src = fopen("a.txt", "rb");
FILE *dst = fopen("dest/b.txt", "wb");
int i;
for (i = getc(src); i != EOF; i = getc(src))
{
putc(i, dst);
}
fclose(dst);
fclose(src);
You need to use the C standard library functions in stdio.h.
In particular, fopen, fread, fwrite, and fclose will be sufficient.
Be sure to include the b ("binary") option in the flags to fopen.
[edit]
Unfortunately, the file names themselves (forward-slashes vs. back-slashes) are still platform dependent. So you will need some sort of #ifdef or similar to deal with that.
Or you can use a cross-platform toolkit.
Use the standard C library stdio.h. First open input file for reading using fopen(inputFilename, "rb") and open output file for writing using fopen(outputFilename, "wb"), copy the content using fread and fwrire. Then close both files using fclose.
How can one create a new file descriptor from an existing file descriptor such that the new descriptor does not share the same internal file structure/entry in the file table? Specifically attributes such as file offset (and preferably permissions, sharing and modes) should not be shared between the new and old file descriptors.
Under both Windows and Linux, dup() will duplicate the file descriptor, but both descriptors still point to the same file structure in the process' file table. Any seeking on either descriptor will adjust the position for the other descriptors as well.
Note
I've since received answers for both Windows and Linux and adjusted the question a little too often, which has made it difficult for people to answer. I'll adjust my votes and accept the cleanest answer which covers both Windows and Linux. Apologies to all, I'm still new to the SO paradigm. Thanks for the great answers!
So basically, what you really want is to be given a file descriptor, and basically open the same file over again, to get a separate position, sharing, mode, etc. And you want to do this on Windows (where the "file descriptor" is basically a foreign object, not something used directly by the OS or the run-time library at all.
Amazingly enough, there is a way to do that, at least with MS VC++. All but two steps of it use only the Win32 API so porting to other compilers/libraries should be fairly reasonable (I think most supply versions of those two functions). Those are for converting a Unix-style file descriptor to a native Win32 file handle, and converting a native Win32 file handle back to a Unix-style file descriptor.
Convert file-descriptor to native file handle with _get_osfhandle()
Get a name for the file with GetFileInformationByHandleEx(FILE_NAME_INFO)1
Use CreateFile to open a new handle to that file
Create a file descriptor for that handle with _open_osfhandle()
Et voilà, we have a new file descriptor referring to the same file, but with its own permissions, position, etc.
Toward the end of your question, you make it sound like you also want the "permissions", but that doesn't seem to make any real sense -- the permissions attach to the file itself, not to how the file is opened, so opening or reopening the file has no effect on the file's permissions. If you really want to know the, you can get it with GetFileInformationByHandle, but be aware that file permissions in Windows are quite a bit different from the (traditional) file permissions in Unix. Unix has owner/group/world permissions on all files, and most systems also have ACLs (though there's more variation in how they work). Windows either has no permissions at all (e.g., files on FAT or FAT32) or else uses ACLs (e.g., files on NTFS), but nothing that's really equivalent to the traditional owner/group/world permissions most people are accustomed to on Unix.
Perhaps you're using "permissions" to refer to whether the file was open for reading, writing, or both. Getting that is considerably uglier than any of the preceding. The problem is that most of it is in the library, not Win32, so there's probably no way to do it that will be even close to portable between compilers. With MS VC++ 9.0 SP1 (not guaranteed for any other compiler) you can do this:
#include <stdio.h>
int get_perms(int fd) {
int i;
FILE * base = __iob_func();
for (i=0; i<_IOB_ENTRIES; i++)
if (base[i]._file == fd)
return base[i]._flag; // we've found our file
return 0; // file wasn't found.
}
Since this involved some spelunking, I wrote a quick test to verify that it might actually work:
#ifdef TEST
#include <io.h>
void show_perms(int perms, char const *caption) {
printf("File opened for %s\n", caption);
printf("Read permission = %d\n", (perms & _IOREAD)!=0);
printf("Write permission = %d\n", (perms & _IOWRT)!=0);
}
int main(int argc, char **argv) {
FILE *file1, *file2;
int perms1, perms2;
file1=fopen(argv[1], "w");
perms1 = get_perms(_fileno(file1));
fclose(file1);
file2=fopen(argv[1], "r");
perms2 = get_perms(_fileno(file2));
fclose(file2);
show_perms(perms1, "writing");
show_perms(perms2, "reading");
return 0;
}
#endif
And the results seem to indicate success:
File opened for writing
Read permission = 0
Write permission = 1
File opened for reading
Read permission = 1
Write permission = 0
You can then test that returned flag against _IOREAD, _IOWRT, and _IORW, which are defined in stdio.h. Despite my previous warnings, I should probably point out that I suspect (though I certainly can't guarantee) that this part of the library is fairly stable, so the real chances of major changes are probably fairly minimal.
In the other direction, however, there's basically no chance at all that it'll work with any other library. It could (but certainly isn't guaranteed to) work with the other compilers that use the MS library, such as Intel, MinGW or Comeau using MS VC++ as its back-end. Of those, I'd say the most likely to work would be Comeau, and the least likely MinGW (but that's only a guess; there's a good chance it won't work with any of them).
Requires the redistributable Win32 FileID API Library
So, I recommend reading up on this a little more. The dup() and related functions serve to create a duplicate value in the file descriptor table pointing to the same entry in the open file table. This is intended to have the same offset. If you call open(), you will create a new entry the open file table.
It doesn't make any sense to create a duplicate of a file descriptor and that new file descriptor have a different offset in the open file table (this seems to contradict what the word "duplicate" means).
I'm not sure what your question is actually. I mean, it isn't the same thing as a duplicate. You could read:
/proc/self/fd/[descriptor]
and get the string that was used to open that file descriptor; bear in mind this may provide some pitfalls, some of which you actually noted in your observation of calling open() again.
Maybe you can explain a little more and I can try to update to help.
Why don't you just open the file a second time with open() or CreateFile() on windows? This gives you all freedom of different access rights and separate offset.
This of course has the drawback that you you can not open the file exclusively, but it solves your problem very simply.