bb.donnay-software.com

We have a program that monitors a watch folder for a file with information needed to pull an individual's credit report.

We currently create the comma delimited information in a string and use memowrit to create the file in the watch folder.

We had an instance where there appears to be some type of contention between the third party program and our software. We had an instance where the export file did not get created. I think the 3rd party program intercepted the file after it was created but prior to the data being added to the file. Thus our program could not create the file. Nothing was processed.

I was inquiring as to some other way of getting the file into the watch folder instead of directly creating via memowrite. May be using the low level file process with exclusive access, but that appears to only be a function of the fopen() process, not the fcreate process. I could make the file hidden then change the attribute. Has anyone had any experience with similar watch folder processes and contention and any recommendations.

Cliff

Cliff,

are you creating a file with a specific name ?

that could be the problem...

create a file with a random name.csv
then
monitor the directory for *.csv

Cliff Wiernik wrote:We have a program that monitors a watch folder for a file with information needed to pull an individual's credit report.

i guess you use a M$ Server ... which Version ?
it seem to me you got SMB2 Directory Problem ... look here
https://technet.microsoft.com/en-us/lib ... 10%29.aspx

"bad" Workaround : use Alaska SMB2 "Hotfix"
"good" Workaround : https://msdn.microsoft.com/en-us/librar ... 85%29.aspx

Are you saying that the 3rdparty program is looking for a file with a specified name?

This is not a MS Server. It is Novell OES server. Workstation running the program is on a win7 workstation. It watchs a folder for any file, checking every 5 seconds. When it sees a file, it opens it and imports it, then deletes it.

We see a similar situation on a ftp site, where one size uploads a zip file and the other side monitors the site for the zip file. Occasionally the zip file downloaded has 0 bytes and then because the downloading side has a built in pause, the file then is put out there with the proper data. In this case, we can fix it if needed.

It is the first instance where we have seen this problem. It appears to only happen sporadically, but does happen. I don't know if first creating to a temporary location and then copying would be better as the file would be intact first.

You could try writing first to a local folder then do a copy to the Novell folder.

Cliff Wiernik wrote:This is not a MS Server. It is Novell OES server. Workstation running the program is on a win7 workstation.

OK ... but your Client Workstation are Win7 and it might be are "Redirector" Problem of MRXSMB20.SYS

Question : on which Port does your Win7 Workstation communicate with NW Server ? UDP 136-139 or 445 ?

Cliff Wiernik wrote:It watchs a folder for any file, checking every 5 seconds. When it sees a file, it opens it and imports it, then deletes it.

Windows Timeout are 10 sec ...

Appears to use port 524.

Hi Cliff,

Can you modify the program that is watching?

I had the same problem in the past. I solved it this way.
I Create the data file with the name abcxyz.txt. When everything is finished, I create a second file with the same name, but another extention. abcxyz.ok. This file is 0 bytes.
The program that is waiting for the data is looking for the OK files. When it sees an OK file, it processes the TXT file with the same name.

This way it never starts processing a file which is not finished yet.

Another solution could be to save the file as abcxyz.notfinished. As soon as it is completely saved, you can rename it to abcxyz.txt. If the watching program doesn't process the notfinished files, it should also work without problems.

Cliff Wiernik wrote:Appears to use port 524.

so it is NOT SMB1 ... as i wrote

it seem to me you got SMB2 Directory Problem ... look here
https://technet.microsoft.com/en-us/lib ... 10%29.aspx