I dont see that as helping the problem. Youd need a sliding window of a set size, say 1 GB that is emptied after that portion is copied - or you could just ignore the problem if its for personal use
Its a buffer implementation - you would need to use something like this for a robust copy solution. if you dont care about supporting larger files you can ignore this
if you do care about supporting larger files - create buffer of say 1GB - load first 1GB of source file and copy to destination - rinse and repeat until file is copied - you might need to seek as well but I think not as I believe C read moves the cursor as well.
If this is for Linux, then I think sendfile() would be fastest, as it happens entirely within the kernel. If you can’t use sendfile() (old Linux kernel, non-Linux Unix system), then I think calling mmap() on the file being copied, then madvise(MADV_SEQUENTIAL) followed by write() would be a good thing.
When writing C you need to check the man page for every function that you use, it will tell you about the values returned when there is an error and you need to check for those and handle them.
wont this fail if source file is larger than RAM? I am guess more robust solutions (
cp,rsync) dont have this issue.It should fail if it’s larger than the available stack size, I think.
How about
char* buf?I dont see that as helping the problem. Youd need a sliding window of a set size, say 1 GB that is emptied after that portion is copied - or you could just ignore the problem if its for personal use
What do you mean a sliding window?
See sbase for an example: concat.c with the sliding buffer / cp.c driving it
Its a buffer implementation - you would need to use something like this for a robust copy solution. if you dont care about supporting larger files you can ignore this
if you do care about supporting larger files - create buffer of say 1GB - load first 1GB of source file and copy to destination - rinse and repeat until file is copied - you might need to seek as well but I think not as I believe C read moves the cursor as well.
You’ve changed the code now to just do:
Won’t that just fail since buf is uninitialized?
I tested it, it didn’t
You’re relying on undefined behavior then, which is inadvisable.
Are you joking? Even the most cursory of checking triggers the warning:
I think OP is learning C.
It’s the first time I see a #include inside a function body!? Any reason you did that? Are you looking for feedback on the code?
I made it a stand-alone function, kind of. I’m stupid. Just forget it
Also the test file is only 7MB? I think most programs that can copy a file could do this under 1 second. Better test might be to get a larger file:
http://ovh.net/files
If this is for Linux, then I think
sendfile()would be fastest, as it happens entirely within the kernel. If you can’t usesendfile()(old Linux kernel, non-Linux Unix system), then I think callingmmap()on the file being copied, thenmadvise(MADV_SEQUENTIAL)followed bywrite()would be a good thing.no need to write(), just mmap() the output file too and even use MADV_DONTNEED.
Not Linux-specific
When writing C you need to check the man page for every function that you use, it will tell you about the values returned when there is an error and you need to check for those and handle them.