Reasons for FileRename to Fail

[DAG_P6]

I have a WB script that contains a large UDF that calls FileRename from two spots. In reviewing the code in preparation for writing this message, I noticed that one of the two calls is in an IF statement that creates one of two log entries, depending on whether or not FileRename succeeded. This I shall fix, but it begs a question.

If a file exists, is not marked read only, and was created by a program that runs in the same security context as this program, what would cause the rename to fail?

• The file is created on a NetWare volume by a program that runs in an account that belongs to a group called DATAEASE.
• The WB script runs on a Windows 2000 server that uses another account that belongs to the DATAEASE group to connect to the NetWare server.
• From the point of view of the Windows 2000 box, the account has Full Control over the contents of the network share.
• The other NetWare user account has all but Supervisor access to the directory, and the file is created without restrictions by a program (PKZIP 2.04g) that doesn't know how to restrict access to it.

What am I missing?

[td]

Permission inheritance for one thing.

[td]

Also, because the creator/owner of an object is a member of a group does not necessarily mean that all members of that group have the same permissions as the owner.  Just a thought...

[DAG_P6]

Thanks for all the ideas to consider. However, something that I neglected to mention is that the problem is intermittent, but the programs that are creating and renaming the files are the same, and they run every day. Each day, a file is downloaded, unpacked, and renamed. Most days, everything goes according to plan. Every now and again, though, the file rename fails, for no immediately apparent reason. A similar operation in a subsequent step usually works; 15 sets of files are processed each night.

[Deana]

In the code that captures the FileRename error, make sure you are getting the extended error information.

Getting Extended Error Information:

Most WIL errors are accompanied by 'extended error information'. Extended error information is written to the wwwbatch.ini file:

"C:\Documents and Settings\{username}\Application Data\WinBatch\Settings\wwwbatch.ini"


There is a section that contains additional diagnostic information that may give some clue as to what it is that failed. 

IntControl 73 returns this same information in the 'wberroradditionalinfo' variable.

Extended error information is most commonly in the form of a Windows system error.

[td]

Good point.  Likely it's an error 5, 32 or 183.

[DAG_P6]

The production code doesn't fully implement the new error handlers that take full advantage of the goodies in the array. Thankfully, the next upgrade does.

It's amazing how clear many problems become when you can see the underlying system error. Sadly, I've seen all three at one time or another.