Text Files Not Closing

[Bill Tillman]

I am having some trouble with writing to text file.

 

(setq g (open "C:/my_folder/logfile.txt" "a"))
(setq str (strcat thedate "  " username "  " dwgno "  " qnum "  Some more text"))
(write-line str g)
(close g)

 

For some reason, the text file is not being closed. That is I cannot delete it after the LISP program completes. Only when I exit AutoCAD completely does the file get closed so I can delete it. I followed the docs on this as best as I can but the file refuses to close.

[Lee Mac]

Are you certain that the program does not / has not thrown an error before the 'close' function is called?

[Bill Tillman]

Ok, it's what I suspected. I'm not actually writing the file to the location indicated. It's a long path to a drive on the Novell servers, which I didn't want to share publicly. If I write the file to the local C:\ drive all is well. But I must write this logfile to the server so this is still a big problem. The IT guys are like deer in the headlights on this. We can chalk this up to another anomaly of working on a Novell server.

 

And yes, the program is exiting without error.

[Bill Tillman]

And are you ready for this....of course one of the first things I try is to do a google search for anything like this. So I go to google, put in "autocad lisp write text file novell close" and it brings up this very post on cadtutor. It appears google get's their updates so quickly now that when you search for help on something you posted only minutes ago, your very own questions show up at the top of the list for solutions....that's google's new algorithm for you.

[BIGAL]

You may need \\ in your file pathing even up to \\\\server\\mycaddwgs etc a single \ often does not work for servers.

 

eg S:\\Autodesk\\lisp\\civ

[Bill Tillman]

You may need \\ in your file pathing even up to \\\\server\\mycaddwgs etc a single \ often does not work for servers.

 

eg S:\\Autodesk\\lisp\\civ

 

That is the case and I discovered that one long ago. If I use the \ (backslash) then I have to double up on them. And with the first pair it ends up being \\\\. I also found that by using the / (forward slash) I can get by without the leading \. Makes no difference which one I use, it all works, so I chose the / method as it uses fewer characters.

 

I was using mapped drives for the first week, but soon found that this user had I:\ mapped to something different than another user. So much for the standards they told me they enforced around here. No worries as writing out the full path is only cumbersome once. I actually use a variable to store this enormously long path. This make life much easier. And if they ever change it on me, all I have to do is edit this one line of code.

 

I did some searches on this and found that it might be or most likely is due to the File Caching or Write Commit settings in the Novell client. The IT guys are too busy with other tasks so I told them to place this on low priority. At the end of the day when the users log out or shut down AutoCAD or the Novell client finally feels like closing the file, it is being updated. I ended up with a very nicely formatted logfile this morning from yesterday's activities. Still, it makes it difficult for me, the programmer, who has to spend time debugging and insuring that the log file process is working. It appears that it is, it's just that I can't view it in real time due to this delay that Novell sets up.

 

Oh yes, I should add here that Excel writes a text file too in this process and there is no such delay with it or at least in the 3 months we've been running this process I haven't experienced it yet. Also, I from time to time edit and re-save this text file when doing tests and it appears that Notepad does not suffer from this delay. But LISP and/or AutoCAD does indeed suffer from this.