FTYP of sub-directories on SDC...

[martyn_hill]

Hi everyone

I've noticed a peculiar behaviour with 'hard' sub-directories on the QL SD-Card when testing the file-type using the TK2 FTYP function.

The file-type returned by FTYP of the root 'SDC1_' is 255 as expected, but for any sub-directories, FTYP returns 0.

Compare this to FTYP on QPC2 against a WIN or DOS drive and both root and all sub-directories return 255.

Fortunately, from a DIR listing, those hard sub-directories have '->' appended, but the FTYP thing is perplexing.

Any ideas?

[martyn_hill]

Hi again!

I forgot to mention that I'm running TK2 v2.23 on this SD-Card equipped QL.

I'll try again with v2.26 then v2.31 and see if FTYP starts to behave as expected...

[martyn_hill]

OK, so FTYP still fails to return type 255 for sub-directories on SDC under both v2.26 or v2.31.

When I get time, I'll review Marcel's updated source for v2.31 and see whether it could get confused somehow by the SDC driver.

Anyone have any thoughts about this?

[tofro]

The file type of a file in a directory is actually stored in two places in QDOS file systems:

1. The File header of the file (or directory) itself, i.e. in the first 64 raw bytes of the file or directory.
2. The copy of the file's header in the directory file of the directory the file resides in

Which is actually a bit silly, as in order to keep everything aligned you'd have to update two places with nearly all file ops.

Some directory drivers apparently store the full copy of the header in only one place of these two for performance reasons. Obviously, the QL-SD driver stores the file type in the wrong place (or, TK2 retrieves it from the wrong one).
In the source code (make_dir, and a very short browse only) of the QL-SD driver, I can find the place where (2) is done, but not (1).

Tobias

[martyn_hill]

Hi Tobias

That makes complete sense - FTYP and the other associated TK2 utilities refer to the channel open to a given file (or implicitly with the \<filename> syntax), which would access the header copy stored in the file itself.

I see two options:
a) Update FTYP (and the others) to access the parent directory of the specified file and extract the relevant file-specs
b) Update the (stand-alone) MAKE_DIR/SDC driver to update both directory and file-copy of the header in the first place.

a) would be heavy-going (having to identify the parent directory - potentially through recursive DIR open calls) so b) would make more sense.

I'll take a look at some point - where did you fnd the source to MAKE_DIR? Is it supposed to be a copy of the SMSQ/E version (which appears to work just fine - at least with the WIN device).

Or is it down to the device driver itself?

[pjw]

How ever it is done, choose a method that is COMPATIBLE with existing systems, so we dont need separate versions of software for each and every platform. Ie, its probably better to fix the driver..

[martyn_hill]

Curious - I took a look myself at both the (F)MAKE_DIR code and also the SDC (EIDDE-based) driver module (edde2_mkdir_asm).

So the TK2 routine is nothing more than a wrapper for the driver (vector $92 in the device definition block), as one might expect.

To my naive eyes, the driver module however does _seem_ to attempt to update both the parent directory file AND the first block of the 'baby' file, as its referred to in the comments (reading around label 'lp' near the end of the mkdir driver module.)

I'll test again this evening - I have a sneaky feeling that MAKE_DIR/SDC driver possibly DID do the 'right' thing originally and update both header copies, but my recent efforts to recover the contents of the SD-Card using WL's terrific QL FileReader (I wrote about this on a separate thread) might have blatted something. The sub-directories are still recorded as such (in the parent directory), but perhaps copying back the entire structure to (a freshly formatted) SD-card using the FileReader program lost something in translation. He does state that QubIDE (and therefore SD-Card) support is only beta...

I'll create a fresh sub-directory using MAKE_DIR and test the output from FTYP again.

Stand-by...

[martyn_hill]

Ha! Would you believe it - testing FTYP again after creating a _new_ sub-directory with MAKE_DIR (from Tk2 v2.26) on the SD-Card finally produces the expected 255!

So, after all that, it would _appear_ that copying the directory structure back from WIN to SDC using QL FileReader might have blatted the file copy of the header, whilst leaving the parent directory copy intact.

I'll test some more before confirming here. Sorry if I've confused anyone reading

[martyn_hill]

OK, so I have now tested creating a new sub-dir on WIN in QPC2, then using QXLWinReader to copy that new sub-dir to the SD-Card (image).

The sub-dir returns 255 from FTYP on WIN, but when the copied sub-dir is checked by FTYP on SDC, it returns 0 again.

So, this appears to confirm my suspicion that the original observation was not a fault with (F)MAKE_DIR nor the SDC mkdir driver module, but an artifact of copying hard sub-directories from WIN to SDC using the (experimental) QubIDE capabilities of WL's - life-saving - QXLWinReader.

I'll report this to WL.

Thanks Tobias for helping me track this down!

[janbredenbeek]

As I remember from a TT interview in QL Today, the original idea behind duplicating the header information in both the directory and file itself was to make microdrives more robust against a damaged directory file. Incidentally, the MDV driver stores the complete file information in the file header while the information in the directory file is incomplete. In the FLP and WIN drivers the reverse seems to be true. This should be transparent to the user though as commands like WSTAT (and AFAIK FTYP etc.) extract the information using the FS.HEADR (or equivalent SMSQ) call and not by using the information read from the directory (this is also the reason why WSTAT takes quite long on MDV since it has to read both the directory and header).

Jan.