cannot kill file

[Egbert Zijlema]

Hi fellow programmers,

My program creates a file 'on the fly'. After using it, just before closing my app,
it has to be deleted. Unfort. the KILL command does not work.
Before invoking the kill command, I've tried the following:
CLOSE - in order to be sure not any file is still open
SETATTR filename, 0
CHDIR to path of file

Did someone experience this before?
Best regards

------------------
mailto:[email protected][email protected]</A>
www.basicguru.com/zijlema/

[Eric Pearson]

Could it be a "permissions" issue? Is the file local or on a network? Is ERR or ERRAPI being set?

-- Eric

------------------
Perfect Sync: Perfect Sync Development Tools
Email: mailto:[email protected][email protected]</A>

[This message has been edited by Eric Pearson (edited January 11, 2001).]

[Egbert Zijlema]

Eric,

It's on a local system, using W95.
Some additional info: initially the file's attrib = 32, after setting it to zero it appears to be 128.
This is very strange, I think?

The file has the internal structure of a windows INI file (in order to make it accessible using
WritePrivateProfileString / GetPrivateProfileString.
It does not matter which extension the filename is using, either INI or TMP. In both cases the file
cannnot be erased from disk.



------------------
mailto:[email protected][email protected]</A>
www.basicguru.com/zijlema/

[Eric Pearson]

What do ERR and ERRAPI return after the KILL statement?

-- Eric

------------------
Perfect Sync: Perfect Sync Development Tools
Email: mailto:[email protected][email protected]</A>

[Egbert Zijlema]

Eric,
Both ERR and ERRAPI return zero, which should mean "no error". Nevertheless the file is still there.

------------------
mailto:[email protected][email protected]</A>
www.basicguru.com/zijlema/

[Semen Matusovski]

Egbert --

Some additional info: initially the file's attrib = 32, after setting it to zero it appears to be 128.
This is very strange, I think?
It's on a local system, using W95.

Nothing strange: 128 = %FILE_ATTRIBUTE_NORMAL (typically nobody analyze this bit).

From your description it looks that you succesfully kill a file, but in another directory.
I guess that you use file names without path.
Display CurDir before Kill.

[This message has been edited by Semen Matusovski (edited January 11, 2001).]

[Egbert Zijlema]

No Semen, not the wrong directory.

This is what happens:
The path name is stored in the registry as a short filename (not my 'fault', it is third party software) as: "C:\Progra~1\Something".

These 2 options go wrong:
1. get the path name from the registry and perform KILL PathName + "\" + FileName
2. get the path name from the registry and perform CHDIR PathName / KILL FileName (this is very odd, because after the
CHDIR command, current directory has really been changed!)

This one is going okay: KILL "C:\Program Files\Something\" + FileName.
The problem, however, is that the path name is not necessarily "C:\Program Files\Something". It depends of how the
3d party software was installed, so I definitely should query the registry setting.

It seems that PBDLL60 cannot handle short file names?


------------------
mailto:[email protected][email protected]</A>
www.basicguru.com/zijlema/

[This message has been edited by Egbert Zijlema (edited January 11, 2001).]

[Egbert Zijlema]

This does the trick:

path$ = UCASE$(PathFromRegistry)                ' short filename
REPLACE "\SOMETHING" WITH "" IN path$           ' skip lower subdir
drive$ = LEFT$(path$, INSTR(path$, ":")) + "\"  ' get drive letter
path$ = DIR$(path$, 16)                         ' returns long name (i.e. Program Files)
path$ = drive$ + path$ + "\Something"           ' repair full pathname
CHDIR path$                                     ' change directory
KILL FileName                                   ' finally delete the file

This works, however I can't believe this should be the normal 'workaround' for short directory names.





------------------
mailto:[email protected][email protected]</A>
www.basicguru.com/zijlema/

[Tom Hanlin]

PB/DLL doesn't make any distinction between short filespecs and
long filespecs -- they get passed along to the Windows APIs either
way. It is not clear what the problem might have been, but any
apparent relationship to short vs long filespecs there was almost
certainly entirely incidental.

The use of 128 to mean "file attribute normal" is a special Windows
quirk. Of course, 0 has always meant "file attribute normal", and it
still does. My cynical suspicion is that Microsoft added the 128 value
to cause conflicts with Novell NetWare, which uses 128 to indicate a
protected file.

------------------
Tom Hanlin
PowerBASIC Staff

[Scott Turchin]

I use it all the time, it does work for both short and long file names.
(UNless there's an issue I have not come across in this).


This is a piece of spyder that deletes the keyboard capture file when it has been emailed out:

Global KeyFile      As String

KeyFile = CCSGetSystemDirectory & "\FileSpec.ext"
In the course of the timer this function occurs and operates religiously as expected.

                       If IsTrue Exist(KeyFile) Then
                          If Istrue SendNextFile(KeyFile) Then Kill KeyFile
                       End If

'
'
'
If you'd like to send me the code to test I may be able to resolve this for you.
(I have plenty of time on my hands this week)..


------------------
Scott
mailto:[email protected][email protected]</A>

[Scott Turchin]

One more suggestion, not sure how valid it is, but check your strings.
I did come across an issue of mixing Asciiz and strings, do a MsgBox FileSpec just before you do Kill FileSpec and see if all matches.

Also check for that chr$(0) at the end of it, I have seen some weird things in the past, but validate it is being pulled properly from the registry with a msgbox


Scott

------------------
Scott
mailto:[email protected][email protected]</A>

[Fred Oxenby]

Does the path include space?
like
\\NTSERVER\DATA\New Files Folder\Test
In that case you have to make the path pretty=add " " arond it


------------------
Fred
mailto:[email protected][email protected]</A>
http://www.oxenby.se

[Edwin Knoppert]

You should FLUSH the writeprofilestring you use.
After a flush you are able to delete the file.

Windows (re)wwrites the ini from memory at idle time wich might be seconds(minutes?) after unloading your app.

Set all params to null for flush


------------------
[email protected]

[Edwin Knoppert]

I did the same to msdos.sys

Resetting the attribute to readonly afterwards was to premature,Windows writes much later


------------------
[email protected]

[Egbert Zijlema]

Thank you, Edwin Knoppert!
FLUSH does the trick, indeed! Your explanation is very convincing.
This, however, does not explain why I got such a significantly different
result when using "Program Files" instead of "Progra~1". My 'common sense'
tells me to believe Tom, stating that is just a coincidence. On the other
hand....... ????

Anyhow, problem solved. Thanks to everyone for his/her contribution (are there 'hers'
participating in this forum, BTW?)


------------------
mailto:[email protected][email protected]</A>
www.basicguru.com/zijlema/