The d_ino is not the inode of the file. I suppose d_ino is the inode of the link in the fd directory.
The d_ino is not the inode of the file. I suppose d_ino is the inode of the link in the fd directory.
I think the way you should take this then is to consider the way in which you are using ftp. You could write a shell script to do exactly what brewbuck is talking about (download the file to a tmp directory and when complete, transfer the file locally to the permanent directory); that would save you these problems.
Of course, that sounds like exactly what you are trying to do. I'm going to guess you are just running ftp with a list of files. If so, take a few steps back to consider the nature of the problem. You should be calling ftp within your C program (or shell script); this way you can wait for it to complete a file, then transfer it.
C programming resources:
GNU C Function and Macro Index -- glibc reference manual
The C Book -- nice online learner guide
Current ISO draft standard
CCAN -- new CPAN like open source library repository
3 (different) GNU debugger tutorials: #1 -- #2 -- #3
cpwiki -- our wiki on sourceforge
This isn't the first time fcntl() has me stumped but I didn't realize it would be going "against-the-grain" so much. The code I have contradicts everything in the man pages. I duplicated your test too and got the same results. I am off to trying something else and in the meantime perhaps someone else might be able to shed some light on this mystery.
FTP isn't broken, but this particular way of using it obviously is.
Is it an FTP client or an FTP server which is depositing the files? If a client, then you can script the activity to move the complete file to the target directory after the download is complete.
If it's a server, then your server is braindead. It's an extremely common task to monitor an FTP upload area for new files. Any FTP server that isn't completely stupid has a way of downloading files to a temporary area then MOVING them to their final location when the download is complete. Exactly because of this issue.
Even better servers give you the ability to run a trigger when a file has been completely uploaded.
Code://try //{ if (a) do { f( b); } while(1); else do { f(!b); } while(1); //}
brewbuck: I'm not sure what you mean.
I have an FTP server which is set to *receive* files. Various people will ftp in and upload a file to the server. It is then the server's responsibility to forward these files (when they are complete) to another computer (which is what my program will do, and that code is no problem). The problem is, I don't know when the files are done being uploaded from the various clients except presumably when the files are closed and ftp is no longer accessing them.
I have no control over what the client does to ftp in the file, so they're most likely to just upload the file directly, rather than uploading it to a temp location and then moving it.
If there's anything the FTP server can do to assist, I'm not sure how to utilize it. As it stands, I look in the directory where the files are coming in, and I see the files created at 0 bytes, and then watch them increase in size as the data transmits through ftp, until the transfer completes. As far as I'm aware, no file movement is happening.
C programming resources:
GNU C Function and Macro Index -- glibc reference manual
The C Book -- nice online learner guide
Current ISO draft standard
CCAN -- new CPAN like open source library repository
3 (different) GNU debugger tutorials: #1 -- #2 -- #3
cpwiki -- our wiki on sourceforge
That being the case I don't see why you need a programmatic solution when a scripted one will do just fine.
Use a shell to script this process and run fuser on the file periodically to see if ftp is done transferring it.
Incidentally fuser is a simple maintenance command instead of a syscall or a stdlib.
BTW which one of the Unixes are you on?Code:man fuser
vsftpd and Debian.