win_extender_bas

[Ralf R.]

Using GETHEAD an SETHEAD does preserve all extra information. One exception is, if you copy an old pre-V2 file with version "0", it is set to version *1*. But that is a minor thing.

I dont have GET/SETHEAD, but you might want to see if it keeps incrementing the version number beyond 1, as SMSQ/E's HPUT/GET does. SET_FUPDT and SET_FBKDT dont affect the version number.

Arvid has taken GETHEAD and SETHEAD, because it was the easiest way to preserve the complete header (beside the backup date) with version number and all dates.

You can of course GET all dates separately and PUT them separately, but not the version. And as COPY_O smashes the update date and backup date, we found the above Extension most useful.

Though I never understood, why COPY set the date to the recent one, this seems to be a uniqe QDOS feature, which unfortunately went over to SMS.

[RWAP]

I suppose that to be allowed to allude to "c lone", my routine should also maintain the access and file type-dependent information if it exists, even when the file type is zero? It seems an awful fiddle merely to pander to an undocumented poke. Anyone using this could simply mark the file as special by using one of the remaining 252 unused file types. Does anyone have an opinion on this?

There are utitlies out there, such as Toolkit III which use some of this extra type-dependent information (eg to add password protection).

[pjw]

I suppose that to be allowed to allude to "c lone", my routine should also maintain the access and file type-dependent information if it exists, even when the file type is zero? It seems an awful fiddle merely to pander to an undocumented poke. Anyone using this could simply mark the file as special by using one of the remaining 252 unused file types. Does anyone have an opinion on this?

There are utitlies out there, such as Toolkit III which use some of this extra type-dependent information (eg to add password protection).

Ok, but it does seem a bit careless, considering that the standard, inbuilt facilities to copy a file from one place to another destroys this information..

[Ralf R.]

There are utitlies out there, such as Toolkit III which use some of this extra type-dependent information (eg to add password protection).

Ok, but it does seem a bit careless, considering that the standard, inbuilt facilities to copy a file from one place to another destroys this information..

I do not believe, that these Information is destroyed, it would meant that copy destroys nearly everything. one bit more to test . And another good reason for Simons Extension .

[pjw]

You can of course GET all dates separately and PUT them separately, but not the version. And as COPY_O smashes the update date and backup date, we found the above Extension most useful.

But the version IS maintained by COPY, at least in SMSQ/E. As you will see with my latest Qlone, all information is easily maintained without the use of any extensions. The exception being extra file dependent information for files of type 0. This is either a deliberate feature of SMSQ/E or a bug which could be fixed.

Though I never understood, why COPY set the date to the recent one, this seems to be a uniqe QDOS feature, which unfortunately went over to SMS.

Yes, it does seem odd. Perhaps we need a new command: COPY_A or BACKUP or something..

[pjw]

Ok, but it does seem a bit careless, considering that the standard, inbuilt facilities to copy a file from one place to another destroys this information..

I do not believe, that these Information is destroyed, it would meant that copy destroys nearly everything. one bit more to test . And another good reason for Simons Extension .

Heres my test rig. Test it and analyse the results yourselves:

Code: Select all

100 SAVE_O 'ram1_tst_bas'
110 CLS
120 FOR t = 0 TO 4
130  ch = FOPEN("ram1_tst_bas")
140  HGET#ch,length, access, type, space, extra
150  v  = FVERS(#ch)
160  dt = FUPDT(#ch)
170  bd = FBKDT(#ch)
180 :
190  HPUT#ch,length, 1, t, 44, 88
200  SET_FBKDT#ch; 99
210  CLOSE#ch
220  PRINT t! 1! t! 44! 88! v! 99
230  COPY_O 'ram1_tst_bas', 'ram1_tst2_bas'
240  ch = FOPEN("ram1_tst2_bas")
250  HGET#ch,length, access, type, space, extra
260  v2  = FVERS(#ch)
270  dt2 = FUPDT(#ch)
280  bd2 = FBKDT(#ch)
290 :
300  CLOSE#ch
310  PRINT t! access! type! space! extra! v2! bd2\\
320 END FOR t
330 :

This is what I get in SMSQ/E (aligned for legibility):

Code: Select all

0 1 0 44 88 1 99
0 0 0  0  0 2  0

1 1 1 44 88 2 99
1 1 1 44 88 3  0

2 1 2 44 88 3 99
2 1 2 44 88 4  0

3 1 3 44 88 4 99
3 1 3 44 88 5  0

4 1 4 44 88 5 99
4 1 4 44 88 6  0

[pjw]

<>
This is either a deliberate feature of SMSQ/E or a bug which could be fixed.

It appears to be deliberate! This from the SMSQ/E sources (file sbsext_ut_copy_asm):

Code: Select all

* Copy one file to another  V0.2   © 1985   Tony Tebby   QJUMP
*
        section utils
*
        xdef    ut_copy1                copy header if type>=1 and copy file

I suppose it could easily be "fixed". But should it? Why was that condition made, I wonder..

[pjw]

There are utitlies out there, such as Toolkit III which use some of this extra type-dependent information (eg to add password protection).

Howsabout this tweak: Replace

Code: Select all

52    COPY_O sdv$ & nm$ TO tdv$ & nm$

with

Code: Select all

52    DELETE tdv$ & nm$: COPY_H sdv$ & nm$ TO tdv$ & nm$

It seems to do the trick, but is largely untested for unintended side effects.

[tofro]

Howsabout this tweak

I used to be pretty sure that COPY_H wouldn't do anything different than COPY on block devices.

I'd have assumed it was invented to force the header being transmitted over pure serial devices (where COPY wouldn't)

Tobias

[janbredenbeek]

I dont know about the "reserved word" at $3A. Anyone?

I believe the long word at $38 was originally intended to store the date of last access (Andrew Pennell's QDOS Companion mentions it as 'reference date'). However it was never used as such. V2 drivers store the version number in one word and the file index number in the other word. The latter is necessary because of the introduction of subdirectories, since there is no linear relationship anymore between directory entry number and the file index number as used in the allocation map.
It also means that the maximum number of files per drive is limited to 65535, or maybe even 32767...

As Ive never seen any program that uses the backup date (though there was a DP program, cant remember which, that supposedly used it) my Qlone routine (somewhere above) omitted to maintain it. As it may be important in some settings, let me therefore rectify that by dumping an updated version in my next post. Id rather only use keywords available in SMSQ/E, and not any external toolkits for this routine.

Way back in 1989 when I got my Miracle 30MB hard disk I wrote a program called HARDBAK that used the backup date to decide whether or not to backup a file. I believe it's also on Dilwyn's archive.

I suppose that to be allowed to allude to "c lone", my routine should also maintain the access and file type-dependent information if it exists, even when the file type is zero? It seems an awful fiddle merely to pander to an undocumented poke. Anyone using this could simply mark the file as special by using one of the remaining 252 unused file types. Does anyone have an opinion on this?

I remember QBOX stored the date of last modification of a MESSAGES_BBS file at header location 10. By comparing this date with the last logon date, QBOX could tell a user if there were new messages in a message area. The file type was still zero though. I wouldn't mind if you don't care about this, though