<notextile>

ExtdAttrib

Introduction

ExtdAttrib distributes queries and changes on attributes. RISC OS standard file attributes are handled
internally.

Each module which wants to provide additional attributes must register itself to this module.
If a program requests attributes for a given file ExtdAttrib passes this attributes to the according
module. These will fill the required attribute information into a attribute result list if they can.
The information can be passed onwards to further modules if required.

The space of memory for the attribute result list is provided by the calling application.
The calling application can determine if its request shall be fulfilled directly or in a multitasking
way if possible. At the latter the caller will obtain a query handle which can be required again
and again until all attributes have been evaluated. The required size of the memory can be determined
also. Because space of result belongs to the caller which might be swapped out during determining
the attributes the values have to be cached locally until the module which provides the information
is polled again by ExtdAttrib.

The calling application has also to pass on a list of attributes which it wants to obtain
for a given file. Attributes are distinguished by tags. The attributes are obtained in the same
order is given inside the list which allows the calling program to fetch attributes which
can be obtained without delay first and fetch attributes at the end whilst improving the obtained
information continuously.

Attributes may be changeable and so ExtdAttrib provides a SWI with which an application
can change changeable attributes of a given file. Even this operation can be performed in a
multitasking way if desired.

What can you do with extended attributes?

The module overcomes some limitations of the OS. E.g. there are filing systems inside
a multiuser network environment which are providing additional information about users
which created or modified the files. The calling application (which is in general the filer)
can evaluate this information on demand. Of course it must be prepared that not all attributes
are available for all files.

Because ExtdAttrib provides handling of arbitrary attributes including sound and graphics
it is easy to implement a thumbnail viewer with it. It also may provide graphical overlay
information for the regular type icon which might eg. indicate which files are checked out
from a file revisioning tool. You can also replace the icons for certain files however.
Attributes can be used to filter files or to search for files. It is also possible to
change attributes for some files like music files independently of the format.

Note this all this is not provided ExtdAttrib itself but may be provided by
additional modules or calling programs.

Displaying attributes

Your application has to enumerate the available attributes first.
According to the reported attribute tags it has to decide whether
to handle an attribute or not. If it wants to handle an attribute it should put it into
a list of required attributes. These list of attributes must be fetched for every file for
which your application wants to report the attributes. This is done by calling the
SWIs ExtdAttrib 0-7. This operation might be performed
in a multitasking way if your application and the according attribute handlers are
performing this. If the result of this query informs your application that an attribute is
writable for the given file your application may provide a possibility to change the
value of the attribute. The change itself should be performed by the application by
calling on of the SWIs ExtdAttrib 16-23.

Attributes

There is a descriptor for each attribute. It contains information about the type of the attribute,
which determines how information is stored inside the query results and also provides some flags
which tells you how an attribute is handled. Such a descriptor
has the following format:

You can obtain a certain attribute descriptor by calling the
SWI ExtdAttrib 9. The same SWI is used to enumerate the
available attributes.

The following attribute tags have been specified in the moment.
All other values are preserved.

How to handle attributes

If you want to write an attribute handler please note the following considerations.
An attribute may be fetched and maintained by several handlers. This can make sense e.g.
think of a handler which keeps music titles inside a separate DB but a title can be also
optionally stored inside the music file itself at certain music file formats.
However it is likely that there are restrictions on the title length on both handlers.
So it makes sense to pass on a fetch to both handlers and to store the longest information
in the result. If an attribute is modified it makes sense to pass the modification to
both handlers so that each handler can store the information as good as it can.

It may be not easy to decide whether it is good to handle an existing
attribute or whether to create a new one. Shall an icon generated by one handler
modified directly by the second handler e.g. by pasting an overlay on it or
shall an overlay provided. The second choice offers the possibility for
the client to choose whether it wants to display the overlays or not and
perhaps in case that there are several overlays in which order they shall
be displayed. Attributes can be designed in some cases in such a way that
they are of interest for a couple of programs. E.g. there may be several
versioning tools but independently of the technical details the attributes
may be the same. In general it would be glad if attributes are providing
additional information that allow filer to handle attributes in a general
way without having handling of every attribute hardcoded.

Please contact … to obtain additional attribute tags.

When a handler is registered it is obtaining a subsequent number which is passed
back to the handler as deregistration tag to allow a unique identification
during the handler deregistration (internally there are 16 Millions tags
available until registration fails. This shall be enough in practice for
a solid operation).

A handler passes the information whether an operation is passed on in
general or not inside the
attribute descriptor. In real action the
handler may behave different in certain special cases (that means that it prohibits
a pass on whilst it reported that it is a pass on handler and vice versa)
even in general it should behave as reported. A handler also passes
a general priority information which affects all its attributes.
Small values are meaning high priority and vice versa.

The handlers for an attribute are called in a certain order.
The order is determined by sorting in such a way that handlers which are not passing
operations on are called at the end of an operation. The next sort level
is the priority information. The last sort level is the order of registration.
Handlers which registered early are called at the end of an operation.
The attributes which are handled by ExtAttrib internally are not passing
on there results, have lowest priority level and are installed at first.
So it is ensured that they are called at last.

A handler must be able to fetch or modify an attribute in a non multitasking
way. It may offer the possibility to fetch/modify an attribute in a multitasking
way. This concept has been chosen to ensure that programs can operate in a non multitasking
way.

A handler modules isn’t allowed to be relocated inside the RMA for there
are absolute references.

Interfaces

ExtdAttrib_FetchAttribute

Fetches an attribute for a certain file.

On entry

R0 = Pointer to pollword (can be also used as identifier for the query).
R1 = Pointer to canonical file name.
R2 = Attribute tag.
R3 = Pointer to required attribute entry to obtain special request data.
R4 = Pointer to result entry for modification. May be 0 if only the required size has
to be determined.
R5 = Pointer to data. This may be either free memory or the actual result. It can be 0 if there is no
further memory or R4 is also 0 to obtain maximal amount of memory.
R6 = Maximal size of free memory or the actual result. The latter depends whether result is
located immediately before free memory (purged flag set) or not. In first case it includes
the free memory whilst in latter case it covers only the actually used memory. If R5 is
0 this value will be be also 0.
R7 = Information flags.

Bit	Meaning
0	1 indicates a new query, else it is a retry.
1	1 indicates that memory is purged which means that the result data is located in front of the free memory.
2	1 indicates that the fetch shall be done in multitasking mode if possible.

On exit

R0 = Result of fetch

Value	Meaning
<0	Error code which occurred inside the handler and should be passed on to ExtAttrib and the client.
0	Noted for multitasking but not fulfilled yet. Try later again.
1	Result modified. Pass on.
2	Result modified. Don’t pass on.
3	Result not modified. Pass on.
4	Result not modified. Don’t pass on.
5	Want to modify. Purge up and retry.

R7 = If result is 1 or 2 this must contain the amount of modified additional memory data.

Use

A handler examines whether it can deliver or update an attribute result for the given file.
If the fetch can be done in multitasking way it must note pointer to pollword and the pointer
to the canonical file name. It can rely on these pointers and their content until a query is
finished or aborted. It can’t rely on the other pointers, so it may have to note the attribute
specific data of the required attribute entry internally. Of course it must queue the request
internally. After doing so it has to return a code of 0 in R0.

After a result has been determined inside a multitasking way it must be buffered until
the handler is requested again. The handler must not write the result into the result
entry or the result data memory whilst it is not requested for there may be
parallel activities. After the handler has determined the result it has to set pollword to non zero.
Therefore it should disable the interrupts, write the pollword word and reenable the interrupts.
The pollword needs not to be set when the handler is in ExtdAttrib_FetchAttribute for the
attribute.

If a handler can’t find a result e.g. for the required attribute doesn’t exists for the
given file it shall leave everything unchanged and return a code 3 or 4 in R0. It shall also
return code 3 or 4 in case that there is already a result but the handler doesn’t want to
modify it.

If a handler wants to modify the result of an attribute its behaviour depends on
the kind of attribute and thereon whether there is already a result or not. In most cases
it will be enough to set the values from offset 4 of the result entry onwards.
Note that the handler has always (even for strings) has to return the exact size
of required data memory in R7 in case where offset 8 contains a offset to additional data.
At strings this must include the terminator. At the flags the handler must not change Bits 0 and
1 which are maintained by ExtdAttrib. After performing the update the handler
must return a code of 1 or 2 in R0. In case that the pointer to the result entry
is 0 the handler can’t evaluate any existing result and can’t write its own result. It
simply has to pass back the required amount of memory in R7 to allow determination
of result memory.

If an attribute makes usage of additional result data this data has to be placed
at that location which is given by R5. The length must no exceed the value given
in R6 and may be limited by additional information as told inside
required attribute entry. Such a limitation
has to be indicated by setting Bit 3 inside the flags of result entry.
If the actual size is not big enough ExtdAttrib can be advised to rearrange the data
in such a way that the additional result data for the actual attribute is located at the end
of used memory. If this is the case or not will be indicated by the purged flag.
If purged flag is 0 and more memory is required the handler can return a code of
4 to request a memory rearrangement after which ExtdAttrib will call the
handler again with the purged flag set. The old entry can be overwritten and
the additionally available memory can be used also. If there is still is not enough
memory the handler shall use as much memory as available and makes sense (e.g. a string
can be shortened but an icon of a specific size can’t) and set
Bit 4 inside the flags of result entry.

ExtdAttrib_Abort

Aborts a pending operation.

On entry

R0 = Pointer to pollword indicating the operation to abort.
R1 = Reason information. If 1 then pending modifications should be made.

On exit

Nothing returned.

Use

The handler removes any internal things related to a pending fetch or modification.
The pending activity is identified by the pointer to pollword.

This call may be done as a result of a SWI ExtdAttrib 9 call.
However it may be caused also by a RMKill of ExtdAttrib and it may occur in case of optimized
modifications to force the handler to perform the delayed modifications.

ExtdAttrib_ModifyAttribute

Modifies an attribute for a certain file.

On entry

R0 = Pointer to pollword (can be also used as identfier for the query).
R1 = Pointer to canonical file name.
R2 = Attribute tag.
R3 = Pointer to modify attribute entry containing the modification data.
R7 = Information flags.

Bit	Meaning
0	1 indicates a new modification, else it is a retry.
1	Reserved
2	1 indicates that the modification shall be done in multitasking mode if possible.

On exit

R0 = Result of fetch

Value	Meaning
<0	Error code which occurred inside the handler and should be passed on to ExtAttrib and the client.
0	Noted for multitasking but not fulfilled yet. Try later again.
1	Modified. Pass on.
2	Modified. Don’t pass on.
3	Not modified. Pass on.
4	Not modified. Don’t pass on.
5	Modified in an optimized way. Pass on. This sets a marker inside ExtdAttrib that something is still open for this modification on this handler and it must be called at the end of modification by ExtdAttrib_Abort.
6	Modified in an optimized way. Don’t pass on.This sets a marker inside ExtdAttrib that something is still open for this modification on this handler and it must be called at the end of modification by ExtdAttrib_Abort.

Use

A handler examines whether it can modify an attribute for the given file.
If the modification can be done in multitasking way it must note pointer to pollword and the pointer
to the canonical file name. It can rely on these pointers and their content until a modification is
finished or aborted. It can’t rely on the other pointers, so it has to note the modification data
of the required attribute entry internally. Of course it must queue the request internally.
After doing so it has to return a code of 0 in R0.

After a modification has been perfomed in a multitasking way the result must be noted until
the handler is called again for the attribute. After the handler has performed the modification it has to set
pollword to non zero. Therefore it should disable the interrupts, write the pollword word and
reenable the interrupts. The pollword needs not to be set when the handler is in
ExtdAttrib_ModifyAttribute for the attribute.

If a handler can’t perform the modification e.g. for the required attribute doesn’t exists for the
given file it shall return a code 3 or 4 in R0. In case that a handler performed the modification
it shall return a code 1 or 2 in R0.

A handler can collect a couple of modifications e.g. for the RISC OS standard attributes and
modify them in one go at the end. However the handler doesn’t know when the last attribute
modification call happens. This may rely on the pass-on information of the other handlers too.
Therefore it returns code 5 or 6 so that ExtAttrib knows that something must be done at the
end and informs the handler by calling ExtdAttrib_Abort.

Service Calls

Service_ExtAttribStarting
(Service Call &)

On entry

On exit

Interrupt

Processor mode

Re-entrancy

Use

You must not claim this service call.

Service_ExtAttribStopping
(Service Call &)

On entry

On exit

Interrupt

Processor mode

Re-entrancy

Use

You must not claim this service call.

SWI Calls

ExtdAttrib
(SWI &)

Performs various actions to obtain and modify file attributes.

On entry

R0 = reason code
Other registers depend on reason code

On exit

R0 preserved
Other registers depend on reason code

Interrupt

Interrupts are enabled.
Fast Interrupts are enabled

Processor mode

Processor is in SVC mode

Re-entrancy

SWI is reentrant

Use

The particular action of ExtdAttrib is given by the reason code in R0 as follows:

R0	Action	Page
0	Fetches file attributes using File$Path non multitasking.	SWI ExtdAttrib 0-7
1	Fetches file attributes using a separate path string non multitasking.	SWI ExtdAttrib 0-7
2	Fetches file attributes using a path variable non multitasking.	SWI ExtdAttrib 0-7
3	Fetches file attributes non multitasking.	SWI ExtdAttrib 0-7
4	Fetches file attributes using File$Path multitasking.	SWI ExtdAttrib 0-7
5	Fetches file attributes using a separate path string multitasking.	SWI ExtdAttrib 0-7
6	Fetches file attributes using a path variable multitasking.	SWI ExtdAttrib 0-7
7	Fetches file attributes multitasking.	SWI ExtdAttrib 0-7
8	Aborts a pending operation in multitasking mode.	SWI ExtdAttrib 8
9	Fetches information about a tag and enumerates the tags.	SWI ExtdAttrib 9
10	Registers an attribute handler.	SWI ExtdAttrib 10
11	Deregisters an attribute handler.	SWI ExtdAttrib 11
16	Modifies file attributes using File$Path non multitasking.	SWI ExtdAttrib 16-23
17	Modifies file attributes using a separate path string non multitasking.	SWI ExtdAttrib 16-23
18	Modifies file attributes using a path variable non multitasking.	SWI ExtdAttrib 16-23
19	Modifies file attributes non multitasking.	SWI ExtdAttrib 16-23
20	Modifies file attributes using File$Path multitasking.	SWI ExtdAttrib 16-23
21	Modifies file attributes using a separate path string multitasking.	SWI ExtdAttrib 16-23
22	Modifies file attributes using a path variable multitasking.	SWI ExtdAttrib 16-23
23	Modifies file attributes multitasking.	SWI ExtdAttrib 16-23

ExtdAttrib 0-7
(SWI &)

Fetches file attributes

On entry

R0 = 0 to 7
R1 = Pointer to object name.
R2 = Optional pointer to path string or path variable.
R3 = Pointer to attribute result memory block.
If set to 0 the maximal required size will be reported without
generating the information.
R4 = Maximal size of attribute result memory block.
R5 = Pointer to list with required attributes.
R6 = Assigned query handle, must be 0 at start of a query.
R7 = Pointer to pollword evaluated at start of a query else ignored.
If 0 at start of a query the pollword is automatically assigned by
ExtdAttrib. If it is non 0 the value is taken as pointer to the pollword.

On exit

R0-R3, R5 preserved
R4 = size of used block when all attributes collected,
else preserved.
R6 = 0 when all attributes collected
else assigned query handle.
R7 = Pointer to pollword for query if query not finished yet. Is kept
during a query.

Use

The operation code determines the kind of file path handling

Bit 1	Bit 0	Path used
0	0	File$Path system variable
0	1	path string pointed to by R2
1	0	path variable pointed to by R2
1	1	none

and the multitasking:

Bit 2	Multitasking mode
0	Single Task
1	Multitask

If SWI is multitasking it returns the query handle and an automatically
allocated pollword in case that a part of the query is processed
in multitasking mode. In this case the according part is stored
internally. You can either call the SWI periodically if you like
or you can wait until pollword becomes non zero. However don’t make
the assumption that if the pollword becomes non zero your query is
entirely completed. It may only have become a bit more complete.
So you may have to poll again and again.

The list containing the required attributes consists of one entry for
each attributed with the following format:

Offset	Meaning
0	Size of entry (incl. this size field) a size of zero marks end of list but without alignment. The size of the optional data can be calculated from this value. The begin of the next entry must be word aligned.
4	Tag of the required attribute
8	Optional attribute specific data which format is determined by the attribute.

The result consists of an array of entries which is preceded by the
number of array elements and followed by detailed data for each attribute
if the information doesn’t fit into the array entry. The array will
be set up at start completely. However the contents of the entries may
change until the query is finished. To find out whether an entry is
valid please check Bit 0 of the flags of an attribute.

Offset	Meaning
0	Number of array elements.
4	Array of result entries. Each entry has the following format: Offset Meaning 0 Attribute tag 4 Flags Bit Meaning 0 Information is valid. May be invalid during queries in multitasking environments (Maintained by ExtdAttrib). 1 Attribute exists for the file (Maintained by ExtdAttrib). 2 Attribute is writable for the file 3 Data is incomplete due to limitation (only with attribute types 4 and 6). 4 Data is incomplete due to insufficient result memory. 8 32 Bit value or offset to data from start if available and required. 12 64 Bit value or size of data.

ExtdAttrib 8
(SWI &)

Aborts a pending operation in multitasking mode.

On entry

R0 = 8
R6 = handle of operation to abort.

On exit

All registers preserved

Use

Aborts the operation belonging to the given handle in multitasking mode.
You must not perform any queries or modifications using this handle until it is
passed again towards you as a result of new file attribute information
fetch/modification.

ExtdAttrib 9
(SWI &)

Fetches information about a tag and enumerates the tags.

On entry

R0 = 9
R2 = Reserved. Must be set to 0.
R3 = Pointer to resulting
attribute descriptor memory block.
If set to 0 the maximal required size will be reported without
generating the information.
R4 = Maximal size of result memory block.
R6 = Attribute tag for which information should be obtained.
&FFFFFFFF indicates first tag in list.

On exit

R0-R3 preserved.
R6 = Number of next tag.
&FFFFFFFF indicates end of tag list

Use

The request will return an attribute descriptor in the given
memory which describes the given attribute. It also returns the attribute tag
of the next attribute (in numerical ascending order) if available so that you can use
this function to enumerate the attributes. However the information is
retrieved directly from the registered attribute handlers. There can be
several handlers registered for the same attribute. Only the information
of the first handler will be returned. There might be slightly different
internal flag information for each handler which must be therefore ignored
by your evaluation.

ExtdAttrib 10
(SWI &)

Registers an attribute handler.

On entry

R0 = 10
R1 = Pointer to registration block.
R2 = Pointer to list of attribute descriptors.
R3 = Handler private word.
R4 = Handler priority. 7 Bit Value.

On exit

R1-R3 preserved
R4 = Handler deregistration tag assigned by ExtdAttrib.

Use

ExtdAttrib 11
(SWI &)

Deregisters an attribute handler.

On entry

R0 = 11
R4 = Handler deregistration tag

On exit

R0, R4 preserved

Use

Handler is deregistered from ExtdAttrib. Pending modifications
shall be perfomed by the handler. Pending queries must be dropped.
ExtdAttrib will remove the handler from its internal structure.
Pending operations will be continued at the remaining handlers if
possible and the pollword will be set to non zero.

ExtdAttrib 16-23
(SWI &)

Changes attributes for a given file.

On entry

R0 = 16 to 23
R1 = Pointer to object name.
R2 = Optional pointer to path string or path variable.
R5 = Pointer to list with modified attributes.
R6 = Assigned query handle, must be 0 at start of a query.
R7 = Pointer to pollword evaluated at start of a query else ignored.
If 0 at start of a query the pollword is automatically assigned by
ExtdAttrib. If it is non 0 the value is taken as pointer to the pollword.

On exit

R0-R2, R5 preserved
R6 = 0 when all attributes modified
else assigned modification handle.
R7 = Pollword for query if query not finished yet. Is kept
during a query.

Use

The operation codes determine the kind of file path handling
and the multitasking in the same kind as described under the fetching of
attributes.

The list containing the modified attributes consists of one entry for
each attributed with the following format:

Offset	Meaning
0	Size of entry (incl. this size field) a size of zero marks end of list but without alignment. The size of the modified data can be calculated from this value. The begin of the next entry must be word aligned.
4	Tag of the attribute which should be modified.
8	Number of modifications performed. Bit 31=1 indicates that modification is complete.
12	Modified attribute data which format is determined by the attribute.

The number of modifications is increased for every modification done by a handler.
If used in multitasking mode the program can evaluate which attributes have been modified for
the file.