Busy/Unfinished File?

What can I use to check for a busy file, ie one that is in the process of
being written?
My app waits for a file to be transfered via TCP/IP (ftp) from a customer’s
system, before processing the file.
Some of these files are very large, and can take tens of seconds to be
transfered.
I know in Qnx2 we could check for the file being busy, but I can’t find the
equivalent in Qnx4.
Thanks,
ms…

Mike Schneider <Mike.Schneider@us.heidelberg.com> wrote:

What can I use to check for a busy file, ie one that is in the process of
being written?
My app waits for a file to be transfered via TCP/IP (ftp) from a customer’s
system, before processing the file.
Some of these files are very large, and can take tens of seconds to be
transfered.
I know in Qnx2 we could check for the file being busy, but I can’t find the
equivalent in Qnx4.
Thanks,
ms…

don’t think there is a clean way of doing this.
suppose you could mimick what ‘sin files’ does, using fsys_fdinfo(), to
wait for ftp to close the file…

how are you ftping the file ? is it interactive ? or via a script ?
you could incorporate the ftplib into your app and then your app would
know when the download is complete.

or maybe something like:
touch the_file_is_busy
ftp the file
rm the_file_is_busy

and your app could wait until the_file_is_busy is removed

ymmv

Mike Taillon <miket@qnx.com> wrote in message
news:8shhun$kf8$1@nntp.qnx.com

Mike Schneider <> Mike.Schneider@us.heidelberg.com> > wrote:
What can I use to check for a busy file, ie one that is in the process
of
being written?
My app waits for a file to be transfered via TCP/IP (ftp) from a
customer’s
system, before processing the file.
Some of these files are very large, and can take tens of seconds to be
transfered.
I know in Qnx2 we could check for the file being busy, but I can’t find
the
equivalent in Qnx4.
Thanks,
ms…

don’t think there is a clean way of doing this.
suppose you could mimick what ‘sin files’ does, using fsys_fdinfo(), to
wait for ftp to close the file…

how are you ftping the file ? is it interactive ? or via a script ?
you could incorporate the ftplib into your app and then your app would
know when the download is complete.

or maybe something like:
touch the_file_is_busy
ftp the file
rm the_file_is_busy

and your app could wait until the_file_is_busy is removed

ymmv

Mike,

The file is ftp’d from the customer’s non-QNX machine to ours,
asynchronously and the only indication we have is the presence of the file.
So, we don’t pull it, they push it.

I did a little test program and found that the st_status field in the
“struct stat” would change from 0x0007 to 0x0003 when the file was
completed, but I couldn’t find the meaning of that bit. Would that bit help
me out?

Thanks,
ms…

Mike Schneider wrote:

The file is ftp’d from the customer’s non-QNX machine to ours,
asynchronously and the only indication we have is the presence of the file.
So, we don’t pull it, they push it.

I did a little test program and found that the st_status field in the
“struct stat” would change from 0x0007 to 0x0003 when the file was
completed, but I couldn’t find the meaning of that bit. Would that bit help
me out?

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
partial/restarted
transfers may be a problem?), although there isn’t an approved/official
mechanism to do this in general that I know of, sorry…

Mike Schneider <Mike.Schneider@us.heidelberg.com> wrote:

Mike Taillon <> miket@qnx.com> > wrote in message
news:8shhun$kf8$> 1@nntp.qnx.com> …
Mike Schneider <> Mike.Schneider@us.heidelberg.com> > wrote:
What can I use to check for a busy file, ie one that is in the process
of
being written?
My app waits for a file to be transfered via TCP/IP (ftp) from a
customer’s
system, before processing the file.
Some of these files are very large, and can take tens of seconds to be
transfered.
I know in Qnx2 we could check for the file being busy, but I can’t find
the
equivalent in Qnx4.
Thanks,
ms…

don’t think there is a clean way of doing this.
suppose you could mimick what ‘sin files’ does, using fsys_fdinfo(), to
wait for ftp to close the file…

how are you ftping the file ? is it interactive ? or via a script ?
you could incorporate the ftplib into your app and then your app would
know when the download is complete.

or maybe something like:
touch the_file_is_busy
ftp the file
rm the_file_is_busy

and your app could wait until the_file_is_busy is removed

ymmv

Mike,

The file is ftp’d from the customer’s non-QNX machine to ours,
asynchronously and the only indication we have is the presence of the file.
So, we don’t pull it, they push it.

would it be possible to have the remote end push 2 files ?
ie.
put realfile
put realfile.done

then your app could compare the st_mtime of each, and would know
that when realfile.done’s st_mtime is greater than realfile’s, the
transfer is complete.

</another hack idea>

I did a little test program and found that the st_status field in the
“struct stat” would change from 0x0007 to 0x0003 when the file was
completed, but I couldn’t find the meaning of that bit. Would that bit help
me out?

Thanks,
ms…

John Garvey <jpg@cisco.com> wrote in message
news:39EC72A5.D1E8158@cisco.com

Mike Schneider wrote:
The file is ftp’d from the customer’s non-QNX machine to ours,
asynchronously and the only indication we have is the presence of the
file.
So, we don’t pull it, they push it.

I did a little test program and found that the st_status field in the
“struct stat” would change from 0x0007 to 0x0003 when the file was
completed, but I couldn’t find the meaning of that bit. Would that bit
help
me out?

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
partial/restarted
transfers may be a problem?), although there isn’t an approved/official
mechanism to do this in general that I know of, sorry…

I think I’ll try the _FILE_BUSY.
We shouldn’t ever get the same file twice within a short time of each other.
As long as the busy bit is never stuck on, then we should be ok.
Thanks,
ms…

Mike Taillon <miket@qnx.com> wrote in message
news:8shtjg$qeb$1@nntp.qnx.com

would it be possible to have the remote end push 2 files ?
ie.
put realfile
put realfile.done

then your app could compare the st_mtime of each, and would know
that when realfile.done’s st_mtime is greater than realfile’s, the
transfer is complete.

We can’t ask the customer to transfer any special files for us.
I’m going to try using that _FILE_BUSY bit that John mentioned.

Thanks,
ms…

We have exactly this same problem. The most basic solution we found is
by using the concept of “cooltime”: A file in the process of being
written to would have it’s modification time updated regularly. If you
let it “cool down” for X seconds and if it has been modified during that
time, you reset your cooltime timer, etc, until the cooltime expires
without the mod time changing. Of course the hard part is to determine
the most optimum value for the cooltime.

Not very elegant, but it’s portable. (We also use this concept on
non-qnx servers)


hope that helps,

rick

Mike Schneider wrote:

What can I use to check for a busy file, ie one that is in the process of
being written?
My app waits for a file to be transfered via TCP/IP (ftp) from a customer’s
system, before processing the file.
Some of these files are very large, and can take tens of seconds to be
transfered.
I know in Qnx2 we could check for the file being busy, but I can’t find the
equivalent in Qnx4.
Thanks,
ms…

Mike Taillon <> miket@qnx.com> > wrote in message
news:8shtjg$qeb$> 1@nntp.qnx.com> …

would it be possible to have the remote end push 2 files ?
ie.
put realfile
put realfile.done

then your app could compare the st_mtime of each, and would know
that when realfile.done’s st_mtime is greater than realfile’s, the
transfer is complete.



We can’t ask the customer to transfer any special files for us.
I’m going to try using that _FILE_BUSY bit that John mentioned.

Hmm, perhaps you could use a seperate small app to do the TCP/IP FTP`ing
to a temp dir, then have that app dump the file once its downloaded it,
to were your App can poll every so often to see if any new files are
in that dir to work on.

take a look at the Free REBOL/CORE for QNX4 http://www.rebol.com
(and loads more OSs) and be sure to ask on their REBOL ML for far more TEC support, or just post a REBOL and QNX how do i post on one of the qdn.*.rtp NGs, some very Experienced REBOLers are
bound to be reading those NG`s .

REBOL/CORE is around 200k in size, does FTP, HTTP put/get, and lots
more advanced stuff, selma Email lists, web servers, web crawlers.

iv been trying to get carl (CEO at REBOL) to hurry the REBOL/View port to RTP and thats comeing along nicely im told, that as you
might guess is a very nice and extended GUI scripting tool with
much of /CORE at its base, check out the web site and download
the free /core and /View for your OS`s to try it.


Thanks,
ms…



Paul May, Manchester, UK
Team AMIGA Central, Phoenix Core

another hack idea

would it be possible to have the remote end push 2 files ?
ie.
put realfile
put realfile.done

then your app could compare the st_mtime of each, and would know
that when realfile.done’s st_mtime is greater than realfile’s, the
transfer is complete.

/another hack idea

I did a little test program and found that the st_status field in the
“struct stat” would change from 0x0007 to 0x0003 when the file was
completed, but I couldn’t find the meaning of that bit. Would that bit
help
me out?

How about register for death messages and checking if ftpd just
terminated. If there is only one file transfer at a time and a smal gap
between two transfer that would work ok I think. Plus you would never
have to pool for the presence of a file

Thanks,
ms…


\