@MSGID: <trycnSKBi4_KZUX5nZ2dnZfqnPadnZ2d@giganews.com>
364caed1
@REPLY:
<d17b6039-834f-48e1-a497-e999884e895cn@googlegroups.com> 4f1a1b95
@REPLYADDR Steven Hirsch <snhirsch@gmail.com>
@REPLYTO 2:5075/128 Steven Hirsch
@CHRS: CP866 2
@RFC: 1 0
@RFC-References:
<d17b6039-834f-48e1-a497-e999884e895cn@googlegroups.com>
@RFC-Message-ID:
<trycnSKBi4_KZUX5nZ2dnZfqnPadnZ2d@giganews.com>
@TZUTC: -0400
@PID: Mozilla/5.0 (X11; Linux x86_64; rv:91.0)
Gecko/20100101 Thunderbird/91.11.0
@TID: FIDOGATE-5.12-ge4e8b94
On 8/10/23 21:54, fadden wrote:
> The CP/M filesystem continues to delight and terrify me.
> 
> As I contemplate the CiderPress II implementation, two questions spring to
> mind:
> 
> (1) Did the CP/M v3.1 filesystem format extensions make it to the Apple II?
> Specifically, the "every 4th directory entry is actually a place to hold
> dates".  I found "CPM3.1Z80_Softcard.zip" on asimov, but none of the disks
> seem to use this feature.

Depends upon the vendor`s implementation.  CP/M-3.x timestamping was always an 
optional feature that required initialization of the directory for those extra 
entries and BIOS implementation to read/write them.  A system that doesn`t 
support them simply ignores the entries since they exist in an "impossible" 
user area.  I`m reasonably sure that the stamping feature was supported by at 
least one or two of the Apple ports.  Off the top of my head, Circom, DRI 
(Gold Card) and ALS all had CP/M-3.x ports for Apple.  There were also a few 
home-rolled ports for Applicard and Microsoft Softcard.

The so-called `Datestamper` scheme was actually far more common in the later 
years of community development.  I added datestamper support to cpmtools a few 
years back, so it now supports both schemes.

> (2) Would it make sense to treat user numbers as directories?  That seems
> like a natural way to handle them, but it does mean the tools would be
> referring to things as "0:FILE.TXT" instead of "FILE.TXT".  I don`t know
> how other tools handle this, absent a "user" command to set the current
> state.  Each disk gets 16 (or is it 31?) pre-defined directories that can
> hold files but can`t be modified.

Referring to user area locations with the N: prefix is quite standard in the 
enhanced CP/M world, e.g. Z-System.  That`s exactly how image manipulation 
utilities like cpmtools manage them.  Only enhanced CP/M implementations 
support user areas > 15. Anything greater won`t be damaged by file I/O, but 
simply won`t be accessible by generic CP/M.  Placing the CCP as 31:ccp.sys 
(lowercase) was commonplace among OEM implementations.

It would be helpful to provide a `move` function to change user area for all 
extents of a given file or set of files.

> An alternative would be to make it an editable file attribute, and just let
> people struggle when more than one file has the same name.  (Not an issue
> in the GUI, problematic in the CLI.)
> 
> A better option would be to include it in the filename, but only when
> nonzero.  So you have "FILE.TXT" and "1:FILE.TXT".  Or maybe "1,FILE.TXT"
> so it doesn`t get confused as a directory name.  Or "FILE.TXT,1".

I would vote for always including the user prefix when listing a directory 
while inferring `0` when none is provided.

I`d strongly suggest taking a look at cpmtools for ideas and concepts about 
mapping between CP/M and current filesystems.

--- Mozilla/5.0 (X11; Linux x86_64; rv:91.0) Gecko/20100101 Thunderbird/91.11.0
 * Origin: usenet.network (2:5075/128)
SEEN-BY: 5001/100 5005/49 5015/255 5019/40 5020/715
848 1042 4441 12000
SEEN-BY: 5030/49 1081 5075/128
@PATH: 5075/128 5020/1042 4441