Greetings!

I'm not sure if I can explain this one very well, but I am going to try.

We are running UniVerse 11.3.5 on AIX 7.2.  We noticed some oddities when writing to a Type 19 file.

At the AIX level, the ownership of the Type 19 file (parent directory) is root, and the group ownership is a group called installs.  UV runs as root.

User xyz (group staff) runs a process that writes to the Type 19 file.  If I monitor the contents of the folder at the Unix level with an "ls -l" command, and my timing is perfect, I will see that the UV record (Unix file) first gets created as a 0-byte file with xyz as the owner and staff as the group.  UV then finishes writing the file and at that time the owner is now root with a group of installs.

This all happens in milliseconds, so trying to capture it 'at will' is nearly impossible.  I just keep running ls command repeatedly until I see it.

I've never noticed this before, but I've never looked before either.  I'm looking now because we have another process (3rd party application on a Windows server) that monitors the folder and picks up the files.  Unfortunately, every once in a while it's timing is 'lucky' and it grabs the file when it's still at 0 bytes.

I am still working through the code, but I am fairly certain we pre-lock the record (before it exists) with a READU - which puts a lock in the UV lock table, but does not appear to create the empty record in the process.  We ran some tests with a test program to check this.  We never caught a 0-byte record in the folder - but maybe we just didn't have good timing?

I am also fairly certain that the program itself only does a single WRITE.  It builds the record and then WRITEs it.  It does not use WRITESEQ.

Has anyone encountered this before? Is this multiple-write/change permissions process normal?

Any and all help is greatly appreciated!

Brian

We've had similar issues with smb shares. Usually because we're building the file over time and not as a single write. I think the technique that seemed to work best was to write the file with a different extension and then rename the resulting file when it's done. The monitoring program would ignore those extensions and only pick it up when it has the correct one.

You could also write it to a different folder on the same drive and then move it to your destination when  it's finished.

Either way you eliminate the problem of working with unfinished files.

Greetings!

I'm not sure if I can explain this one very well, but I am going to try.

We are running UniVerse 11.3.5 on AIX 7.2.  We noticed some oddities when writing to a Type 19 file.

At the AIX level, the ownership of the Type 19 file (parent directory) is root, and the group ownership is a group called installs.  UV runs as root.

User xyz (group staff) runs a process that writes to the Type 19 file.  If I monitor the contents of the folder at the Unix level with an "ls -l" command, and my timing is perfect, I will see that the UV record (Unix file) first gets created as a 0-byte file with xyz as the owner and staff as the group.  UV then finishes writing the file and at that time the owner is now root with a group of installs.

This all happens in milliseconds, so trying to capture it 'at will' is nearly impossible.  I just keep running ls command repeatedly until I see it.

I've never noticed this before, but I've never looked before either.  I'm looking now because we have another process (3rd party application on a Windows server) that monitors the folder and picks up the files.  Unfortunately, every once in a while it's timing is 'lucky' and it grabs the file when it's still at 0 bytes.

I am still working through the code, but I am fairly certain we pre-lock the record (before it exists) with a READU - which puts a lock in the UV lock table, but does not appear to create the empty record in the process.  We ran some tests with a test program to check this.  We never caught a 0-byte record in the folder - but maybe we just didn't have good timing?

I am also fairly certain that the program itself only does a single WRITE.  It builds the record and then WRITEs it.  It does not use WRITESEQ.

Has anyone encountered this before? Is this multiple-write/change permissions process normal?

Any and all help is greatly appreciated!

Brian