help: different OPEN extended modes

[Alex Chupahin]

Hello!
During porting clamav I just get a trouble:

...
...
des = open(file, mode, right, "ctx=bin");
...
...

then code analyzes file content and choose the one of the scanner ( zip, arj, html, etc.)

The problem lies in the fact that one of the file type (html) should be opened with
"ctx=stm","rfm=stmlf"

What can I do when the file has been opened yet as "ctx=bin". How can I "reopen" file by his descriptor with new attributes?
I have a variant: save scanning file name to the external variable and close then open file with new attributes, but I dont like it - not estetic and broke logic of the program.

[Steven Schweda]

Why don't you use "ctx=stm","rfm=stmlf"
always? I would expect UNIXy programs not
to care. For example, UnZip doesn't seem to
care:

alp $ zip fred.zip *.pdf
adding: CLEAR_SEL__13421.PDF (deflated 50%)
adding: ZX2000_GETTING_STARTED.PDF (deflated 1%)
adding: ZX2000_QUICK_SETUP.PDF (deflated 2%)
adding: ZX2000_TECH_REF.PDF (deflated 3%)

alp $ pipe dire /full fred.zip | sear sys$input "record "
Record format: Fixed length 512 byte records
Record attributes: None

alp $ set file /attr = rfm:stmlf fred.zip

alp $ pipe dire /full fred.zip | sear sys$input "record "
Record format: Stream_LF, maximum 512 bytes, longest 512 bytes
Record attributes: None

alp $ unzip -t fred.zip
Archive: ALP$DKA0:[SMS.ZX2000]FRED.ZIP;1
testing: clear_sel__13421.pdf OK
testing: zx2000_getting_started.pdf OK
testing: zx2000_quick_setup.pdf OK
testing: zx2000_tech_ref.pdf OK
No errors detected in compressed data of ALP$DKA0:[SMS.ZX2000]FRED.ZIP;1.

[Alex Chupahin]

> Why don't you use "ctx=stm","rfm=stmlf"

No.
I'm mantain porting clamav for 2 years and research many sides of the various problems with it.

for archives the best should be ctx=bin,
for html should be "ctx=stm","rfm=stmlf"


So I should "reopen" file with new mode.
Can I do that?

[Hein van den Heuvel]

Well, the c-rtl has a freopen call.
But best I can tell that just does a close + open.
In which case I would prefer the explicit close+open.

What are you worried about? One extra file open for a file which header and data are in the XQP and XFC caches? 'cleanliness'?

Just FYI... it is NOT going to be as easy as chasing down the file pointer and flipping a bit or two. A lot of the C-rtl internal control block changes when flipping this. Some stays (fab, rab)...

1602: fp = fopen( argv[1], "r", "ctx=stm" );
DBG> s
stepped to SCF\main\%LINE 1603
1603: return (fclose ( fp ));
DBG> set rad hex
DBG> ex/octaw @@fp:(@@fp)+70
0000000000664BB0: 0004034900668000 0066800000000216
0000000000664BC0: 400040000066C000 0066800000000003
0000000000664BD0: 0000000000000000 0000000000667610
0000000000664BE0: 0000000000000216 0000000000000000
0000000000664BF0: 0000000000000000 0000000000000000
0000000000664C00: 0000000000000000 0000000000000000
0000000000664C10: 0000000000000000 000000000066DE10
0000000000664C20: 006675A000664D10 006675F000000000

DBG> ex/asciz 000000000066DE10
000000000066DE10: "TMP.COM"

SDA> show proc/rms=(rab,fab)
FAB Address: 00664D10
RAB Address: 006675A0

1602: fp = fopen( argv[1], "r", "ctx=bin" );
DBG> s
stepped to SCF\main\%LINE 1603
1603: return (fclose ( fp ));
DBG> set rad hex
DBG> ex/octaw @@fp:(@@fp)+70
0000000000664BB0: 000003490066E000 0066E00000000013
0000000000664BC0: 7FFF800000676000 0066E00000000003
0000000000664BD0: 0FFFFFFFF00000000 000000000066DE20
0000000000664BE0: 0000000000000016 0000000100000000
0000000000664BF0: 0000000000000000 0000000000000000
0000000000664C00: 0000000000000000 0000000000000000
0000000000664C10: 0000000000000000 000000000066DE10
0000000000664C20: 006675A000664D10 006675F000000000


fwiw,
Hein.