Skip to main content

AcuServer and C$COPY

  • April 17, 2020
  • 2 replies
  • 0 views

Hi;

We've been using AcuServer on Windows Server for years to accept files from other locations.  Files are transferred to a specific folder on the server and a service consumes them once files are fully transferred.  Our application uses C$COPY to copy files from a local folder to the server location, using remote name for the server filename.

Recently, we have issues with files coming from just one location - which does have a slow, unreliable internet connection.  Monitoring files from this location, we see the file appear in the folder, and we can see neither the size, date, nor time gets updated on the file for over a minute.  The file does eventually transfer completely.

What happens, though, is our process to consume files will sometimes think the file is done, because the size/date/time hasn't changed in 120 seconds - the process is able to open the file and consume it, but the file isn't, in fact, finished transferring.

Does AcuServer not use Windows file locking when using C$COPY to transfer a file from a Windows client to a Windows server?  Is there any option to use Windows file locking, so that our process would recognize the file is still locked by AcuServer, or an option to have the date/time/size modify more often while the transfer is happening?

Thanks for any suggestions

Tony

2 replies

Hi;

We've been using AcuServer on Windows Server for years to accept files from other locations.  Files are transferred to a specific folder on the server and a service consumes them once files are fully transferred.  Our application uses C$COPY to copy files from a local folder to the server location, using remote name for the server filename.

Recently, we have issues with files coming from just one location - which does have a slow, unreliable internet connection.  Monitoring files from this location, we see the file appear in the folder, and we can see neither the size, date, nor time gets updated on the file for over a minute.  The file does eventually transfer completely.

What happens, though, is our process to consume files will sometimes think the file is done, because the size/date/time hasn't changed in 120 seconds - the process is able to open the file and consume it, but the file isn't, in fact, finished transferring.

Does AcuServer not use Windows file locking when using C$COPY to transfer a file from a Windows client to a Windows server?  Is there any option to use Windows file locking, so that our process would recognize the file is still locked by AcuServer, or an option to have the date/time/size modify more often while the transfer is happening?

Thanks for any suggestions

Tony

AcuServer does not lock a file while it is being transferred.

One option is to use 2 separate files, one of which does not exist until the main file is done being transferred, and to only consume the transferred file once the "done" file exists.

For example, if you want to consume myfile.txt, then don't do it until myfile.done exists, and then have the transferring program first transfer myfile.txt, and when complete to create myfile.done. The consuming process would then consume myfile.txt, and then delete both files.

Sorry, but we don't actually do anything with the size and timestamps for files. We let Windows do that, and in fact have no control over it.


  • April 17, 2020

AcuServer does not lock a file while it is being transferred.

One option is to use 2 separate files, one of which does not exist until the main file is done being transferred, and to only consume the transferred file once the "done" file exists.

For example, if you want to consume myfile.txt, then don't do it until myfile.done exists, and then have the transferring program first transfer myfile.txt, and when complete to create myfile.done. The consuming process would then consume myfile.txt, and then delete both files.

Sorry, but we don't actually do anything with the size and timestamps for files. We let Windows do that, and in fact have no control over it.

Thanks, that's helpful.  We'll resolve this with the sentinel file approach.