RC5 crash when loading macro

[Clark]

Running out of disk space when writing the state file will cause it to be corrupt.

(Unix only) It's also possible to get a corrupt state file if you open two instances of SlickEdit and file locking is either turned off or not working. This is almost guaranteed to happen if file locking isn't working and you run two instances of SlickEdit. You can use a "-st 0" invocation option if file locking isn't working for you. You can test this by running two instances of SlickEdit and trying to write the state file out with the "write-state" command. In the future, we may default to "-st 0". This preloads the entire state file into memory.

[rowbearto]

Thanks Clark.

How to know if I have file locking turned off or not working? I attached a screenshot of my File/Load options.

Is there any harm for me to use "-st 0" all the time to prevent corruption?

I invoke SE from a script so I can easily add that in there if it would help. What are the disadvantages to using "-st 0"?

Sounds like best for me to use "-st 0" as it seems my file was already corrupted, so this should help prevent it.

[Clark]

Using -st 0 all the time is fine especially if you have an ssd. It can slow down start up. The file locking option I'm talking about is the -sul invocation option which turns off all support for file locking. Some Unix systems don't support it and you can get annoying messages when locks aren't working.

There's no gui option for file locking on the state file.

[rowbearto]

SSD is not an option for me because the Linux machine is in an NIS domain and my home directory is over an NFS file system. And I sometimes like to use different linux machines in our network so it is convenient to have my configuration in a network accessible place.

startup time is not so bad even though it is over NFS.

I will keep the -st 0 option in my script so that I always use it.

My script is below, is it correct?

/home/robb/programs/linux/se_latest_x64/bin/vs -st 0 $* &

[Clark]

That works. Hard drives are much faster than they used to be. This option is a bit ancient. It also will cause the editor to take a little more memory but it's insignificant for today's modern machines with 2 gigs or more of memory.