I need to copy a file (srcFile) to a new ubication (destFile). Then I calculate the size of the copy file using stat. The problem is that I always get a cero size value although the file has not cero size in the hard disk.
The source code that does this is :
PROGRAM 1:
char srcFile[MAX_FILE_SIZE];
char destFile[MAX_FILE_SIZE];
int fileDest = 0;
strcpy(srcFile, "/dir1/file1.bin");
strcpy(destFile, "/dir2/newfile1.bin");
int rf = 255;
if (rf = rename(srcFile, destFile))
{
// Process error
}
struct stat dest_info;
int sr = stat(destFile, &dest_info);
printf("New file size is %d", dest_info.st_size);
Please, can you help me to solve this issue? Thanks in advance.
Why don't you show us the whole source file? And, it wouldn't hurt to tell us what language you're using (one might assume it is C, but with all of the missing pieces needed for a valid C program, that is just a seemingly reasonable guess). And, show us what diagnostics were printed when you tried to compile your source code.
With what you have shown us there are lots of undefined values and undeclared functions without even considering that there is no main() function in your code.
Having code that says // Process error to handle errors, is a great way to ignore errors and have absolutely no idea whether or not anything worked. I would suggest that you actually put code in that section to issue a diagnostic if the rename() failed. And add checks to verify that the strcpy() and stat() calls also worked or print diagnostics and exit if any of them failed.
One might also note that you said your code is intended to copy of file. It does not copy a file. It attempts to move a file (removing the source file if the rename() succeeds); not copy it.
As Don says, it's not possible to determine what this code is actually doing. However, it occurs to me that, it could be simply creating a link (and leaving the original file in-situ). If you then stat the link (inode) location you will likely get a zero length. However, when you list that link it will show the original file size.
However, please answer Don's questions and post what OS you are using.
Hi hicksd8,
Assuming that there is no power failure, disk failure, disk controller failure, CPU failure, memory failure, etc. between the time of the creation of the new link and the removal of the old link; the old link will be removed if a new link was created as a result of a rename() request. If the original file size was greater than zero, you should never end up a with a zero size original file and a non-zero new file size as a result of just a rename() request.
My guess would be that one of the following happened:
/dir1/file1.bin and /dir2/newfile1.bin reside on different filesystems, the rename() is failing with an EXDEV error, the stat() is failing because the new link was not created, and the zero size is coming from uninitialized data on the stack in the struct stat ;
there is an existing /dir2/newfile1.bin that has size zero that the user invoking this program doesn't have permission to remove (getting an EPERM error from the rename() ) and the code falls through the rename() failure and gets and prints the size of the unmodified destination file; or
everything went as expected creating a new link, the stat() succeeded, and the printf("New file size is %d", dest_info.st_size); successfully printed the high order bits of an object of type size_t (which is a 64-bit type on most current systems) using %d (which prints a 32-bit integer on most current systems).
But, lots of other problems are also possible with missing #include directives, unknown compiler diagnostics and warnings while the code was being built, etc. and we have absolutely no way to determine what happened with the information we have been given to analyze.
Yep, we're all trying to guess what's happening here and none of us have enough information to know exactly.
The OP says it's a copy operation which infers that the OP expects the source to still exist after the operation. However, 'rename' is in the code.
I was attempting to explain the OP comment that his code outputs a zero length for the destination but when he lists the file it's the correct size. Given that detail I suggested that the destination was in fact a link and not a copy, and that somehow, the process fails before the inode was populated with the allocated sectors of the file. So the destination shows length zero but the source (which the OP expects to still exist) shows the correct size.
I 'guess' that we can't 'guess' any more without more info. Really sorry that I tried only to confuse the conversation.