Repeat command and archives

It would be nice to have an option in the *Repeat command to treat arvhives as directories instead of files.

Is this possible? I am so used to, for example, having to delete the old ROMimage archive before downloading the new one, just because I have ArcFS already running (Directory already exists!).

But is this not “down to” ArcFS itself, and not the OS as such?

Or have I, a non-expert, misunderstood something vital? I await being illuminated!

I do understand that there is a flag to identify image files as such.

It would be nice to have an option in the *Repeat command to treat archives as directories instead of files.

If you run a second Repeat command for the particular filetype, you can make an obey file the Repeat command and do the expanding and further Repeat actions from there. I cant recall if Spark allows you to work directly for writing but archive files generally are going to have to be expanded, worked on, and re-compressed.
Using an Obey file for/in place of the Repeat command argument, allows you as many lines of processing as required, and then another Repeat action on the newly formed directory of files.
From memory, the archive name will get passed as “%0” to the secondary obey file
HTH

Or have I, a non-expert, misunderstood something vital? I await being illuminated!

Image files are identified by being a different filesystem object type. So when a program gets the attributes of an object, or enumerates the contents of a directory, instead of seeing “file” or “directory” it will see “image file”. This means that each program is free to choose whether it should treat it as a file or a directory.

However, there is an extra wrinkle, which is that an image file will only be reported as such if the appropriate image filing system module is loaded. The special “image file” status is applied at runtime, it isn’t stored on-disc at all. This can be the source of some inconsistencies in behaviour.

In the case of Repeat, it looks like the current implementation will completely ignore image files. So we’d probably want to fix it so that it will by default treat image files as files (to match behaviour when the relevant FS isn’t loaded), as well as adding a new option to allow them to be treated as directories.

When I wrote my !Cat application to list the files on a disc (or within a directory) I treated image files (if reported as such – i.e. image filing system loaded) as a directory if the option ‘Open image files’ was ticked but otherwise as a file. I didn’t need to do anything special as all the complicated bits were done by the image filing system.

as well as adding a new option to allow them to be treated as directories.

To be complete, consider Application directories also. I guess that would allow using Repeat as a basis for file search, list or archive creator (already has the luxury of selecting filetypes)
Edit: and if it had a recursive option it would save creating an extra obey file for the iteration.
I read in the source that although the BootUtils module has the *Repeat command, the repeat program is outside of the module in Resources:?
Probably some deep meaning for this to do with tasks, I don’t know.

Surely Application directories are just normal directories?
Are they treated by Repeat any differently to normal directories?

Surely Application directories are just normal directories?

If the command needs a filetype of directory, the application directories are ignored (different filetype) However if Repeat had a recurse function it may make the need for specifying a filetype of directory redundant. I guess the new recursive option would have to recognise both types as being the same or be selectable,
I think at the moment running Repeat for each directory type might work.

To be complete, consider Application directories also.

I think you may be confusing object types with file types. PRM 2-44 & 2-70 say that OS_GBPB 12 returns an object type (at +16: 0 = not found, 1 = file, 2 = directory, 3 = image file [i.e. both file and directory]) an object filetype (at +20: -1 = untyped, use load address, &1000 = directory, &2000 = application directory) and a filetype (at +0 from load address in bits 8-19 if bits 20-31 all set).

Application directories are just directories and although they have a datestamp, the returned datestamp is that of the !RunImage file inside the directory if present. Image files are not returned as a directory – either the image filing system is loaded (in which case they are returned as object type 3) or it is not (and they are returned as object type 1). I have added the option to !Cat to force treatment of object files as files rather than as directories. This means that zip archives and StrongHelp files (for example) can be listed as files rather than as a directory along with its contents. !Cat always operates recursively to ensure contents of every directory are listed.

Application directories are just directories

Maybe I was locked in to using the type option thinking it was the only way.
*Help Repeat
shows that there is already an option for directory/application selection and you can have both.