Hello Peter at al.,
As I recall - One of my original design ideas with HDS 4 was the ability to have a mixed-mode file with records in both formats.
This got too complicated and was shelved during development - so that now a file has to be in one of the two formats overall. Records can be individually converted while they are being copied and it should be (is???) possible to convert file formats by copying.
I would guess that the "sticking plaster" logic was from an interim time when the record conversion was not working 100% successfully and I cannot see why temporary files should not adhere to the global setting.
Brian
-----Original Message-----
From: Starlink development [mailto:[log in to unmask]] On Behalf Of Peter W. Draper
Sent: 24 April 2012 09:50
To: [log in to unmask]
Subject: Re: HDS temporary files bug or feature?
On Mon, 23 Apr 2012, Tim Jenness wrote:
> On Thu, Jul 7, 2011 at 3:54 AM, Peter W. Draper <[log in to unmask]> wrote:
>> I've been attempting to debias some big mosaic sets using CCDPACK and
>> not having much success, the usual error being a report about an
>> integrity check failure.
>>
>> Cutting a long story short the underlying problem seems to be that
>> the HDS temporary file being created is version 3, not 4, so HDS runs
>> out of accessable disk space, and the reason for this is that I have
>> an old version
>> 3 GLOBAL.sdf file in my ~/adam directory!
>>
>> The problem tracks to a hack added by Brian back in 2006: f74775b96c521:
>>
>> BKM sticking plaster repair to Tim's test.sdf datMove bug!
>>
>> /* This is a sticking plaster - fix!!!!!!!!!!!!!!!!!!! bkm 20060306
>> */
>> if( rec_gl_endslot > 1) {
>> hds_gl_64bit = rec_ga_fcv[rec_gl_endslot-1].hds_version >
>> REC__VERSION3;
>> tmp_save = hds_gl_c64bit;
>> hds_gl_c64bit = hds_gl_64bit;
>> } else {
>> hds_gl_64bit = hds_gl_c64bit;
>> tmp_save = hds_gl_c64bit;
>> }
>>
>> In this case rec_ga_fcv[rec_gl_endslot-1] is my GLOBAL.sdf file, so
>> the temporary file is also created as version 3.
>>
>> Hmm, I guess you could argue who needs a version 3 temporary file (or
>> this should use the proper hds_gl_64bit value), but I cannot recall
>> what that datMove bug was.
>>
>
> Did this get resolved?
Not to my knowledge.
> I have a message from Brian about it:
>
> On March 7, 2006 3:24:58 AM HST, "McIlwrath, BK (Brian)"
> <[log in to unmask]> wrote:
>> I have spent some time recently getting back into HDS and looking at
>> your test.sdf datMove bug. I am somewhat disappointed to see that,
>> what I hoped was a simple mode-switch logic bug is rather more tricky!
>> Basically the logic for moving HDS records between different format
>> files where the control structure sizes differ needs more thought. I
>> have commited a couple of "sticking plaster" temporary patches to CVS
>> which you can use (or not) for now. One will make datMove give an
>> error if a move of records between different format files is
>> attempted while the other attempts to create the temporary data file
>> in the correct format!
>>
>> I am, at least, clear now as to what I need to do to fix things
>> properly BUT I am leave until 19th March from this evening.
>>
>> I will get back to this record move problem ASAP when I get back. It
>> needs to be made 100% solid or it will keep hitting us again and again!
>
> but clearly never got back to it.
>
> I am a bit confused though. The temporary file should be forced to
> 64BIT on copy because the Starlink login explicitly sets HDS_64BIT to
> 1. Do you leave it unset?
I just leave the value at whatever the login sets, that is it is set.
Cheers,
Peter.
|