@FILEOPEN with W(rite) empties file!

#1
Maybe everyone else knew that but I didn't. I just lost a good one testing
Code:
SET h=%@FILEOPEN[%0,w,t]
as a means of preventing another instance of TCC from running a BTM.

I know the behavior isn't going to change since it has been around since shortly after the big bang (at least back to 4NTv8). But isn't it a bit harsh?

The help says "To open a file for both reading and writing, open it in append mode". But what if I don't want to read ... I only want to write, say change one character at a known location.

As it is, @FILEOPEN's distinction between "write" and "append" is not what most would expect it to be.

I doubt it would have helped me but the help should say LOUDLY that the W(rite) option causes the file to be emptied.
 
#3
This is normal Windows behavior (not TCC-specific). If you open a file for write, it gets truncated. That goes way back to MS-DOS.
That's the (unfortunate) behavior of the CRT (if you use L"w" or L"w+". You can do better. This doesn't destroy the contents of the file.
Code:
HANDLE hFile = CreateFile(L"v:\\hello.txt", GENERIC_WRITE, 0, NULL, OPEN_ALWAYS, 0, NULL);
CloseHandle(hFile);
 
#5
99.9% of the time, when you specify a "w" you want to overwrite any existing file. Your approach would make that impossible, and you'd end up with a new file composed of some new content and some old content.
I guess you're right there, since I apparently just discovered the behavior after 20+ years with 4DOS, 4NT, and TCC. I'm just cranky because I have to re-write a BTM. A newbie not familiar with C's mode characters might make the same mistake. It should be made clearer in the help.
 
Jun 2, 2008
284
1
Newton, MA
#6
I'm just cranky because I have to re-write a BTM.
What, you hadn't backed up that file?! Even though I have cloud backup (and regular backup to external disk), I still have CascadePoint running for just such situations. You presumably had to save the file to test-run it, so CP would have saved it (along with previous versions).

-- Jay