Andrew Thomas <email@example.com> wrote in message
“Rick Mullholand” <> firstname.lastname@example.org> > wrote in message
news:> email@example.com> …
I’m trying to determine if a file is busy, but I’m having
difficulty in finding how to do it. In the file fsys.h is
a #define for _FILE_BUSY. The file says that they are
bits in the d_status element of the dir_entry structure.
I have used opendir and readdir to get the file names in
the directory but a file that I know is being written
to never tests as _FILE_BUSY.
Could someone educate me on the correct method to test
for a file being busy?
I have noticed that _FILE_BUSY will not work if your file is on
a node other than the node that is testing the flag. It also appears
not to work reliably on a local node, but I’ve never been able to
discover the rules for its validity. I don’t believe that _FILE_BUSY
is POSIX, and I have not encountered any other OS that offers
it (that I’ve found, anyway). I think the proper method to test for
a file being busy is to change your algorithm so that you do not
depend on this flag. “Busy” is, after all, a somewhat undefined term
when you consider that there is caching both in Fsys and in the user
program. Also, busy for read? Busy for write?
Just sharing my experience. I’d like to hear the official answer
This isn’t official, but it may help?
The following is a portion of a previous thread, when I had the same
I had the same problem when I was waiting for a file to be completely ftp’ed
to me. I used the ‘struct stat’ in the stat() function and used the
st_status and _FILE_BUSY, but it wasn’t 100%. What I ended up doing in
addition to this check is to save the last modification time (st_mtime), and
then check it again after a few seconds to see if it’s changed. If the file
isn’t busy and hasn’t changed I proceeded. In my case however, I could wait
10 seconds without a problem.
(Qnx2 did have a file write-busy bit, as I recall.)
Bit 0x04 is indeed _FILE_BUSY, but it doesn’t quite mean that. It means
that the file has allocated physical disk space beyond the logical EOF.
It will be cleared when the file is close()d (but also when the file is
ltrunc()d or fsync()d). Also, if the file already exists and was not
opened O_TRUNC (i.e. there are disk sectors already associated with the
file) then this bit will never be set initially. So, depending on the
operation of ftp, this may indeed work for you (although
transfers may be a problem?), although there isn’t an approved/official
mechanism to do this in general that I know of, sorry…