Kill Statement fails and file system permissions maybe

HCL Domino Domino Forum
1

I am working on an application for a customer that uses the LotusScript “Kill” statement to delete a temporary file. Works great on my systems, but at my customer site, the kill statement runs like it doesn’t exist. No error message…just doesn’t work. I am therefore ruling out my code as the problem because it runs fine in my test environment.

Their antivirus and windows gurus didn’t think anything with Mcafee or windows NTFS file permissions was “wrong”, as the user can go into file manager and delete it no problem.

Notes ECL allows the action.

The feature is in the left frame, a Notes form with meta data, in the right frame the acrobat file displayed via the IE control. The Queryopen script on the form detaches the PDF to a temp PDF file (using “ap” plus the NOTEID of the document plus “.pdf”) and also saves the name to a Profile keyed for the user. The right frame launches a URL to the file name in the Profile. Works excellent. But then I try to delete the file on disk when the user leaves the document…that is where Kill statement comes into play. In the Queryclose, I Kill the same file name by reconstructing the name using the NoteID. But again, Kill just doesn’t work (at the client site).

One thing that may be a clue…but I am not sure how to understand this, is when I open a document here, the Notes window tab says “C;\notes\data\ap542.pdf” but at the client site the window tab says "ap542.pdf (no path name). I asked about how they run Notes, and it is the same as my installation…all local, no terminal server or shared EXEs or anything. A straight-up local installation.

I also tried the NAME function to just rename the temp file to overwrite a temp file name, but that doesn’t even work here. So I gave up that approach.

I am stumped…and of course this capability is part of a new feature that they really need (and I sold them on it).

I have of course searched everywhere for an answer (web, IBM and VB/MS forums, etc.), but no one except me has run into this, I guess. Obvious syntax problems with the Kill statement don’t apply here because it works great here. Some other mysterious power at work at the client site that I don’t yet understand (call me grasshopper).

Thanks for any help!

2

Subject: Kill Statement fails and file system permissions maybe

Hi Kent

Just a stupid question: Does your agent have the highest permission rights (2nd tab, full admin rights).

Cheers

Bodo

3

Subject: Kill Statement fails and file system permissions maybe

Kent,

I agree with first response. Also, your comment about the c:\notes\data\filename vs. filename may be relevant, as I think the kill statement expects a full path.

When I have a similar kind of problem one test I like to do is have someone manually dump a file called something like raphael.txt with just a line of text in it. I then run code to kill it, and try the permutations of c:\notes\data\raphael.txt, or just raphael.txt, etc. This is more relevant in a scheduled agent against mapped drives but it still may be helpful for you.

regards,

raphael

4

Subject: Kill Statement fails and file system permissions maybe

It doesn’t sound like this is too likely in your situation, but I have had the exact same behavior when the file is in use. It just skips it - no error message or anything. The other thing I now do before a kill is set up my path manually. The only place I use kill is where I created the file so that I have control over exactly where it’s located, so it looks like this:

fileName$ = "C:\exports" + taxid + “.xls”

If Dir$(fileName$) <> “” Then

'file exists - kill it – this won’t work if the file’s in use at the time

Kill fileName$

End If

Hope this helps!

5

Subject: Success! Windows 2000 versus XP versus Acrobat

OK, it only took a day, but I got it figured out. Thanks to everyone for their ideas! A good check on my sanity and made me go back and check my work so far to make sure I wasn’t doing anything stupid.

Here is how the day went. I had three test machines…W2000 NTFS, XP NTFS, XP FAT. I rotated Notes 6.5.5 and 7.0.2 installations through all of them. Also installed Notes in c:\notes and data in c:\notes\data (like my customer) and in c:\notes and c:\data to see if that mattered.

In tests launching Acrobat in IE through that right side frame, I discovered that Kill can successfully delete files on either type of XP file system, any version of Notes. But could NOT kill files on W2000, any version of Notes. So W2000 is the problem so far, I am thinking (also have various versions of Acrobat, including 4, 6, and 8, but that didn’t matter).

Now that I know that W2000 is the problem in general, what is the specific problem? My customer has a mix of W2000 and XP. I learned that Kill fails silently. So I tried Shell’ing out to do a DOS “del”. Didn’t work. Also fails silently. Then I tried the Windows API call (Declare Function SHFileOperation Lib “Shell32.dll” Alias “SHFileOperationA” (lpFileOp As SHFILEOPTSTRUCT) As Long) and you wouldn’t believe it. On W2000, Acrobat held the file handle open even after it seemed to close…and the win API call barfed with “file contention error”. Aha! Try the test on the XP boxes, and no problems are reported because apparently Acrobat on XP releases the file immediately, and consequently the file can be deleted in the form Queryclose event.

So…what’s a chap to do? Re-architect the whole thing, of course! Fortunately all users already have a personal Profile doc as part of the application design to remember the name of the PDF that is extracted to disk (then the frame opens the file name it gets from the profile doc). So, now when a new PDF is launched, the file name (full path of course) is added to a MV list in the profile doc. No attempt is made to delete the PDF in the form queryclose event, but now the database Queryclose event grabs the list of file names that were opened and loops through them, killing one at a time. If any of the files are missing from disk (such as the user manually deleted them while the application is open), the filenames are removed from the list in the profile doc. Any unsuccesfully killed files (such as the user opened one in Acrobat while the application is open) stay in the list for next time the database closes.

Whew! Customer will be very happy. Thanks again for your help!