Saving file causes appending of thousands of NULL chars to file header

[yaniv]

Hi,
I've been using Slickedit for long time on Windows XP, and after installing same version ( 16.0.0) on Windows 7, when I try to save file(without actually editing it), then Slickedit appends tens of thousands of NULL chars to the beginning of the file.
I searched Google, and in this forum, and it appears I'm the first one to encounter such issue.
Please advice.

[Dan]

We haven't heard of an issue like this.  Here are a few questions that will help us figure out what is happening:

• Does this happen with every file?
• If not, how large is the file?  What type of file is it?  What are the extra characters that you are seeing?
• If you save the file by typing "save +o" on the SlickEdit command line, does it still happen?

[yaniv]

Dan,
Thanks for the quick reply.
- Yes, it happens with various file extensions (all of which I tried).
- File size has funny impact on this. It appears that the Slickedit appends the exact number of original chars of the file as NULL chars (I used the Hex view after re-opening the file). For example, if I use 0x20 chars, it will append 0x20 chars of '\0'
- "save+o" on command line has the same affect as above.

[Dan]

Is your configuration pretty stock?  What emulation are you using?

Can you PM me a file before/after so I can see this?

[yaniv]

Hi,
After deleting "My Slickedit Config" from "My Document", and reconfigure the Slickedit, problem solved.
Still not clear how it came to do such a bad thing.

Issue closed.
Thanks,
Yaniv

[Dan]

Odd.  Please let us know if you see any more of this.

[herager]

Hi
I actually see this problem too, and Removing 'My slickedit config' does not help.
I happens when opening a file over a network connection, the Null bytes inserted seems to depend on the file size and are appended again for every save.
Opening a file on the local harddrive works fine.
(NB! Opening file and saving it in another program works fine)
I have attached files: original + after 1,2 and 3 saves

I hope you can come with a fix for this
  Peter

Win XP: SlickEdit 2011 (v16.0.0.6 32-bit) - CUA emulation

[Dan]

Try closing SlickEdit and restarting it with a -s3 invocation option.

[herager]

That worked
What is -s3 doing ?

[Dan]

It avoids certain file related system calls that tend to be problematic on network file system (Samba in particular).  They're valid calls, so we want to use them where we can (for performance).

[mwb1100]

It avoids certain file related system calls that tend to be problematic on network file system (Samba in particular).  They're valid calls, so we want to use them where we can (for performance).

I wonder if there might be a reasonable way for SE to automatically figure out if those calls are 'safe' to use or not (without killing performance).  I don't see this problem, but I'd hate to have it creep up on me with me being aware for a while (even if it seems like it would be easy to fix).

Maybe the first time a drive/volume/share is accessed do a 'safe' API call and an 'unsafe' call and compare the results - if there's any problem, do whatever -s3 does from then on.

[Charlie]

I've noticed this too, though it's more like 10's of null characters sprinkled throughout .c files. I am editing local files. (Win7, SE 16..0.0.6 64 bit)

[Mike]

You can set an environment variable which will invoke the aforementioned attribute when a new instance is started:
VSLICK=-s3