The REXX interface to OS/2 EAs (extended attributes) is quite simple, three functions are all you need (and get):
| SysGetEA( file, name, var ) | see also | view rexx sysgetea |
| SysPutEA( file, name, val ) | see also | view rexx sysputea |
| SysQueryEAList( file, stem ) | see also | view Orexx sysqueryealist |
Here file is the path to an existing file or directory on a file system supporting EAs. Incomplete list of result codes, you could use SysGetMessage(n) to display these and other codes:
| 0 | okay | |
|---|---|---|
| 2 | file not found | (e.g. "C:" won't work, use "C:\") |
| 3 | path not found | (e.g. ".\" won't work, use ".") |
| 12 | access denied | (e.g. device names "/dev/nul", "\con", or "kbd$") |
| 32 | file is locked | (e.g. "C:\ea data. sf") |
| 254 | invalid EA name | (e.g. more than 255 char.s or any '"*/:<>?\|') |
| 282 | file system doesn't support EAs (e.g. CDFS or TVFS drive) | |
Although you can have a "wp root. sf" file on a TVFS drive used by the WPS to store EAs like .CLASSINFO, implicit translations like "C:\" to "C:\wp root. sf" don't work on TVFS drives. Of course all other TVFS files and direcrories redirected to ordinary files and directories work as expected.
There is no visible difference between FAT and HPFS EAs, the 32+9 "*/:<>?\| characters not allowed in EA names are identical. On my system even a DOS tool like NDD (Norton disk doctor) didn't corrupt the OS/2 system file "C:\ea data. sf" used to store EAs in a FAT.
If SysGetEA returns 0 (okay), and the EA value (stored in var) is an empty string '', then the specified EA name does not exist for the given file or directory. Similarly you can delete any EA with SysPutEA, specify an empty string '' as new value.
Unfortunately old versions of REXUTIL.dll have no SysQueryEAList . You may be able to use RxFuncAdd for the OREXUTIL.dll (object REXX) version of SysQueryEAList , or replace SysQueryEAList by the almost identical function DosEAList found in Quercus REXX REXXLIB.dll or QREXXLIB.dll as entry LIB_DOSEALIST. On my system (WARP 3 fixpak 40 with classic REXX) REXUTIL.dll has SysQueryEAList , but I have to use OREXX.INF instead of REXX.INF to read its online manual entry.
New versions of REXUTIL.dll also contain SysFileSystemType to get the file system type like FAT, HPFS, CDFS, TVFS, etc. for a given drive. The Quercus REXX function DosFileSys found in REXXLIB.dll or QREXXLIB.dll as entry LIB_DOSFILESYS is equivalent.
One important feature of EAs is to store long file names on FAT drives as .LONGNAME EA. This EA is also important on HPFS drives, because HPFS doesn't support characters like CR d2c(13), LF d2c(10), or '/'.
BTW, using CrLf to get line breaks in WPS object titles is possible, but the WPS also treats '^' as line break, and HPFS supports '^'. Use '^' to avoid otherwise unnecessary .LONGNAME EAs for file system objects.
On HPFS physical file or directory names and corresponding .LONGNAME EAs should only differ for illegal characters (control or "*/:<>?\|), the WPS uses an exclamation mark '!' instead of illegal characters. To get rid of '!!' representing CrLf in the title use the object settings notebook or function SysSetObjectData with e.g. 'TITLE=what^ever'.
You could also try REN on the command line, but REN does not modify or even remove the .LONGNAME EA. In fact REN is a perfect way to cause confusion with completely different physical names and .LONGNAME EAs corresponding to object titles. On my German system I had a directory with title Filme and physical name MOVIES under MMOS2. It could be worse, e.g. titles with umlauted characters, and then try to change your primary codepage from 437 or 850 to 1004... ;-)
WPS objects can have a unique object id. like <WP_DESKTOP> used (not only) by REXX scripts to identify these objects later. Obviously this includes file system objects, <WP_DESKTOP> is a directory. The WPS stores object id.s in its registry OSSYS.INI using the application PM_Workplace:Location. The object id. is the key, and the WPS handle is the value. This scheme is safe enough for abstract objects like shadows or program objects, because the informations needed to use abstract objects (handle, class, location, title, and other setup info) are also stored in OSSYS.INI.
BTW, OS/2 shadows (references) don't have a title, this might be a difference from Windows 2000 (?). Normally shadows also don't have an object id., but with SysCreateObject instead of SysCreateShadow it's possible to set an object id. even for shadows. See also the entry for procedure RENO in the REXXTRAP manual.
File system objects are implicitly persistent, even more persistent than abstract objects, because files and directories still exist if OSSYS.INI was deleted or corrupted. Therefore object id.s of file system objects are also stored as part of the .CLASSINFO EA for the corresponding file or directory. For the weird sequence of SysIni, SysSetObjectData, and SysSaveObject necessary to modify object id.s later see procedure RENO in rexxtrap.cmd.
Like object id.s icons for file system objects are stored in OSSYS.INI (application PM_Abstract:Icons) and as EAs. The idea is probably to survive the corruption of either EAs or OSSYS.INI.
EA .ICON is the normal icon, and .ICON1 is the icon used for open objects. Finally EA .ICONPOS notes the last known location on the desktop. Elsewhere I've seen the info that this is a WARP 4 EA, but on my WARP 3 Connect system EA .ICONPOS also exists.
SysSetIcon( file, ico ) is a shorthand to set EA .ICON using the specified *.ICO file. You can even use SysSetIcon in a makefile: @rexxtry exit 1-SysSetIcon('$(FILE)','$(ICON)')
A corresponding SysGetIcon doesn't exist, to get and save the icon of a file use SysGetEA( file, '.icon', 'data' ) and charout( ico, substr( data, 5 )) as a minimal solution. Sometimes EAs are corrupted, better check it:
if SysgetEA( file, '.ICON', 'data' ) = 0 then do
okay = length( data ) - 4 /* skip EAT_ICON and length */
if 0 <= okay then do /* little endian => reverse */
okay = ( okay = c2d( reverse( substr( data, 3, 2 ))) )
okay = okay & abbrev( data, x2c('F9FF'))
if okay then call charout ico, substr( data, 5 )
end
end
To set the icon of abstract objects use SysSetObjectData( objectid, 'ICONFILE=' || ico ) or specify ICONFILE= in the setup string of SysCreateObject. I have not yet tested the SysSetObjectData method, maybe it doesn't set EA .ICON for file system objects. See also the entry for procedure MAKE in the REXXTRAP manual.
Associations work with types and filters. In OS/2 terminology "filters" are patterns matching filenames, generally something like *.cmd (or *cmd with a subtle difference). Types defined as extended attributes start to make sense with *.hlp files, where the filename is not enough to determine the corresponding applications, e.g. View for OS/2 help files, WinHelp for WIN 3.1 help files, QH for MS QuickHelp files, etc.
Associations for a type are used if a .TYPE EA is found, and if an association for one of the specified types exists. Otherwise the associations for filters are used (probably in a first match first served manner, but I haven't tested this). It's possible to associate one application with more than one type or filter, and it's possible to have several applications associated with any given type or filter. In other words, associations are n:m relations.
Some types like Plain Text (case sensitive) are used by the system. For details see also the chapter on EAs in the Control Program Guide shipped with the OS/2 Programmer's toolkit, or better check out Bernd Schemmer's REXX tips and tricks available on Hobbes. On my system I invented types like OS/2 HLP file, Win HLP file, and QuickHelp for different *.hlp files. Of course a type without at least one associated application would be quite useless, and the proper way to introduce new types would be a unique prefix like a company name to avoid potential conflicts.
The WPS manages lists of associations under the OSSYS.INI applications PMWP_ASSOC_CHECKSUM, PMWP_ASSOC_FILTER, and PMWP_ASSOC_TYPE. I've never used these applications with SysIni directly, because the settings notebook of program or file system objects allows to manipulate associations freely, and there are tools like ASSOEDIT.exe (PM) or DEFASSOC.exe (VIO) simplifying these maniulations. DEFASSOC.exe is a part of Henk Kelder's famous WPTOOL32.ZIP (400 KB).
Associations for programs, e.g. *.exe files, are also stored in EA .ASSOCTABLE. Don't confuse programs (file system objects) and program objects (abstract objects), see the Control Program Guide for details.
All EAs have a name and a value. EA names starting with a dot (among others) are reserved by IBM for future OS/2 extensions, unfortunately unlikely today. The dot-EAs are also known as SEAs (standard EAs), for the usage of some important SEAs like .LONGNAME etc. read the previous chapters and the Control Program Guide.
All SEAs follow the convention that their value starts with a word indicating the EA type, followed by further bytes depending on this EA type. Some EAs like REXX.LITERALPOOL and REXX.VARIABLEBUF don't use this convention, i.e. the value returned by SysGetEA is all you get, but note that EA names starting with 'REXX.' are no SEAs and therefore free to use an opaque structure for the corresponding EA values.
Some EA types, especially those used for SEAs, are reserved for the system (0x8000 .. 0xFFFF), other EA types (0x0000 .. 0x7FFF) could be added by users. Actually the lists of SEAs and EA types is quite small, on my system I found the following SEAs:
| SEA name | EAT (EA type) | Remarks |
|---|---|---|
| .APPTYPE | EAT_BINARY | or EAT_MVMT (used instead of .CHECKSUM?) |
| .ASSOCTABLE | EAT_MVMT | struct, see Control Program Guide |
| .CHECKSUM | EAT_BINARY | no normal CRC32 (maybe CRC of uncompressed binary ?) |
| .CLASSINFO | EAT_BINARY | |
| .CODEPAGE | ? | |
| .COMMENTS | EAT_MVMT | German WPS: Kommentar |
| .EXPAND | EAT_ASCII | printer driver stuff |
| .EXPANDHARDWIRED | EAT_ASCII | printer driver stuff |
| .HISTORY | EAT_MVMT | German WPS: Protokoll |
| .ICON | EAT_ICON | closed icon |
| .ICON1 | EAT_ICON | active icon |
| .ICONPOS | EAT_BINARY | WARP 4 (seen on WARP 3 ?) |
| .KEYPHRASES | EAT_MVMT | German WPS: Schlüsselwort |
| .LONGNAME | EAT_ASCII | normal ASCII, not ASCIIZ |
| .PPDIMPORTING | EAT_ASCII | printer driver stuff |
| .PREVCLASS | EAT_BINARY | WARP 4 |
| .SUBJECT | EAT_ASCII | German WPS: Verwendungszweck |
| .TYPE | EAT_MVMT | (or EAT_ASCII) |
| .VERSION | EAT_MVMT | (or EAT_ASCII, maybe EAT_BINARY) |
For .SUBJECT, .HISTORY, .KEYPHRASES, and .COMMENTS see the corresponding pages in the settings notebook of any file system object. The .SUBJECT length is limited, but still long enough to convert good old Norton Commander DESCRIPT.ION files.
Most other SEAs are discussed in the previous chapters, and that's all I know about these SEAs. The description of SEA .CODEPAGE in the Control Program Guide is very obscure, and I found no SEA .CODEPAGE on my system. The OS/2 linker probably creates either SEA .APPTYPE or .CHECKSUM, but I don't know how: .CHECKSUM is apparently no CRC32 of the binary.
The predefined EA types conventionally used for SEAs and other EAs are short words in little endian order: 2 bytes, least significant byte first. Reverse these bytes in REXX scripts, e.g. use abbrev(var, x2c('FEFF')) to match an EA value in variable var with EA type EAT_BINARY (0xFFFE, -2 ).
| first word: type (EAT) | second | third word or data | ||
|---|---|---|---|---|
| -1 | FFFF | not used as EAT | ||
| -2 | FFFE | EAT_BINARY | length | length bytes |
| -3 | FFFD | EAT_ASCII | length | length char.s |
| -4 | FFFC | EAT_ASCIIZ | (obsolete, see below) | |
| -5 | FFFB | EAT_BITMAP | length | length bytes |
| -6 | FFFA | EAT_METAFILE | length | length bytes |
| -7 | FFF9 | EAT_ICON | length | length bytes |
| -17 | FFEF | EAT_FILE | (obsolete, see below) | |
| -18 | FFEE | EAT_EA | length | length char.s (EA name) |
| -33 | FFDF | EAT_MVMT | codepage | item number, 1st EA, etc. (maybe nested) |
| -34 | FFDE | EAT_MVST | codepage | item number, EAT, 1st item data, etc. |
| -35 | FFDD | EAT_ASN1 | ? | |
The former EAT 0xFFFC was ASCIIZ, i.e. an ASCII string terminated by NUL d2c(0), but this EAT is obsolete based on comments in bsedos.h shipped with the OS/2 toolkits 2 and 3. The application EAS.exe in the toolkit 3 directory SAMPLES\OS2\EAEDIT still uses a hardwired EAT 0xFFFC ASCIIZ and another obscure EAT 0xFFEF FILE, but otherwise you shouldn't see these obsolete EAs on any OS/S 2.x system (WARP 3 is 2.30, WARP 4 is 2.40).
MVMT stands for Multi-Value-Multi-Type, and its structure is EAT_MVMT, codepage (or 0), number of items, 1st item, 2nd item, etc. Each item is again an EAT, in theory you could nest MVMT. In practice I've only checked SEA .TYPE, and there each item was EAT_ASCII including some weird empty (length 0) EAT_ASCII strings.
MVST stands for Multi-Value-Single-Type, and its structure is EAT_MVST, codepage (or 0), number of items, EAT, 1st item, 2nd item, etc. On my system I found neither EAT_MVST nor EAT_ASN1, and the codepage of all found EAT_MVMT was 0. Please note that the Warp 3 Control Program Guide and Reference is erroneous, one obvios case is the organization of .KEYPHRASES as EAT_MVST illustrated by an EAT_MVMT example. In fact all .KEYPHRASES found on my system are organized as EAT_MVMT.
Somehow EAs can be flagged as critical, i.e. required by an application using these EAs. The REXX procedures don't allow to access the flags. In EAUTIL /S format the flags are the first byte of an EA. With KEDIT, my favourite editor, I can set EAPreserve ON|OFF|CRITical, and EAP CRIT would save only EAs flagged as critical. Old DOS applications without LFNS (long file name support) are not allowed to modify files with critical EAs. Old applications started in a native DOS session could of course modify critical files on FAT-partitions.
The structure of split EAs created by EAUTIL /S is simple:
In this example the value of .CLASSINFO would start with 2 bytes x2c('FEFF') for a reversed EAT_BINARY followed by 2 bytes length x2c(7A00), and for this SEA you're not surprised to get x2d(007E)=4+x2d(007A). Note the little endian order, length x2c(0201) would be 258 = x2d(0102) and not 513 = x2d(0201).
The archive rxos2eas.zip contains six REXX scripts to manage EAs on a system:
EAKILL.cmd is a batch script to remove EAs supporting wild char.s with EAUTIL.exe, something like @for %%F in (%1) do @EAUTIL %%F NUL /S
One thing I tried was to split all EAs on a FAT drive with EAUTIL /S for all files in all subdirectories. This creates subdirectories EAS to hold the split EAs, e.g. if C:\msc\hlp\alang.hlp had any EAs, then they are removed from "C:\ea data. sf" and saved in C:\msc\hlp\EAS\alang.hlp.
My idea was to clean up (shrink) "C:\ea data. sf" somehow, but it didn't work. After all EAs had been removed, the file was quite small, so recreating it from scratch won't help much. At least I learned that OS/2 locks "C:\ea data. sf", and to get rid of it would require more than a single OS/2 session. Therefore I restored all EAs with EAUTIL /J, removed the then empty EAS subdirectories, and noted this EAUTIL story here as nice try... ;-)
DIRLOCKS.cmd is a simple script used as template for the CHECK??? scripts. Maybe you can also use it as template for scripts doing something with each file (and optionally each directory) in a tree starting with any given directory (see procedure SUBS in the code).
One interesting observation before you try e.g. 'DIRLOCKS C:\' to find all locked files on drive C: SysFileTree can block, if a file name contains invalid characters depending on the actual codepage.
On my system I had this problem in a directory with a file name containing x2c('E4 F6 FC'), the lower case of German umlauted characters x2c('C4 D6 DC') in codepage 1004, when the actual codepage was 850.
CHECKEAS.cmd creates a file CHECKEAS.tmp in your TMP directory listing all EA names plus EA types translated to human readable EAT names like MVMT etc. Each combination of EA name and type is counted. If the counter would be 1 the corresponding file is listed directly, you can later check unique combinations manually.
CHECKLNS.cmd header as found in rxos2eas.zip:
OS/2 REXX: check .LONGNAME attributes removing redundant EAs.
observations:
- OS/2 translates "invalid" char.s like CR, LF, or "/" to "!"
- CrLf in .LONGNAME ("!!" in name) could be replaced by " ^"
- .LONGNAME is a normal length preceeded string (not ASCIIZ)
- .LONGNAME can be invalid (user can remove invalid .LONGNAME)
- redundant .LONGNAME is silently removed (any error is shown)
- .LONGNAME of ?:\DELETE\* is silently ignored (used by UNDEL)
- .LONGNAME on a CDFS not supported (strange) and not checked
- .LONGNAME of locked files cannot be read or removed
- if any .LONGNAME is found the user can...
...accept it (press ENTER or Y)
...reject it (press N), and if rejected the user can...
...delete it (press ENTER or Y, any error is shown)
...otherwise the SETTINGS view of the file object is opened
- user can press ESC in all dialogues to terminate the script
- script can be used on CMD line, via PMREXX, or as PM program
- some directory trees (see below SKIP.0 etc.) can be skipped:
Here "see below" means "edit the next script lines as needed on your system". On my system I skipped AWK\GAWKTEST installed on a FAT (numerous long names *.good instead of FAT *.GOO were not really interesting), and three other subdirectory trees, where too many long names differed from the file names for known and sound reasons. ?:\DELETE directories are automatically skipped.
Use CHECKLNS.cmd on the command line without argument to get a short usage info. Use argument asterisk * to (re)create a WPS object for CHECKLNS.cmd. Otherwise specify a drive or diretory to check long names of all files in the specified subdirectory tree.
CHECKLNS.cmd silently ignores long names "almost" identical with file names, i.e. /\ or CrLf replaced by ! .
CHECKLNS.cmd silently removes redundant long names, if US ASCII upper case of long name and file name are identical. If you need mixed case long names in a FAT corresponding to mono case file names do not use CHECKLNS.cmd or disable procedure KILL.
For all other differences between long and file names CHECKLNS.cmd asks you what to do: accept it as is (default), delete the EA, or open the settings notebook, where you can edit the title manually.
The handling of VIO vs. PM and different arguments in CHECKLNS.cmd were probably overkill, and I didn't use it in the other scripts. OTOH the interactive use of CHECKLNS.cmd as PMREXX or PM program makes sense, because you can't open a settings notebook without WPS... ;-)
CHECKTYP.cmd header as found in rxos2eas.zip:
OS/2 REXX: create a list of all EA .TYPE found on local disks,
use CHECKTYP without argument to get a .TYPE-report, see below
usage: CHECKTYP [REDUCE|REPAIR|REMOVE|type]
Observations:
- .TYPE should be MVMT (0xFFDF), but often it's ASCII (0xFFFD)
- an early test showed 965 MVMT vs. 646 ASCII, in a later test
917 of 940 MVMT contained a single ASCII item, the remaining
23 MVMT contained two ASCII items
- NetScape 2.02 uses ASCII for its MIME types, including weird
.TYPEs like "application/x-unknown-content-type" (34 char.s)
- obviously (ckecked with WPS) it's possible to reduce MVMT to
ASCII if it contains only one item => call this script with
argument REDUCE to replace MVMT by ASCII where possible
- argument REDUCE only replaces MVMT with codepage 0 by ASCII,
on my system all .TYPE MVMT EAs used the default codepage 0
- argument REDUCE corrected numerous length errors implicitly,
to correct more errors explicitly use argument REPAIR (this
also removes invalid .TYPE EAs, e.g. neither ASCII nor MVMT)
- REDUCE and REPAIR implicitly corrected cases, where MVMT EA
contained a single additional NUL byte, shown as "error x00"
- note that REPAIR cannot yet fix all possible MVMT problems,
but on my system it was enough to REPAIR all MVMT problems,
see also the restriction for REDUCE (codepage 0 and 1 item)
- argument REMOVE deletes ASCII .TYPEs of the form ?/x-? like
application/x-gzip or image/x-icon (unregistered MIME type)
- please check <WP_NOWHERE> and NETSCAPE.INI files manually to
get rid of Netscape's associations with REMOVEd ?/x-? .TYPEs
- to find more than 1 file using any given .TYPE specify it as
argument (e.g. PLAIN TEXT, case insensitive)
- you cannot match a void .TYPE (i.e. ASCII length 0), this is
done automatically if no argument is specified - you'll then
find counters like 1 MT+: or 2 CII: in the report instead of
the usual tags MVMT+: or ASCII: (see below report format)
- converting ASCII to MVMT is simple, x2c( FD FF 00 00 01 00 )
added before any valid ASCII EA - sorry, not yet implemented
Report format:
- report lines in the form "MVMT n item(s)" plus COUNTER show
a counter of MVMT .TYPE EAs with n=1 etc. item(s), otherwise
report lines are either TAG TYPE FILE or TAG TYPE COUNTER if
TAG TYPE matches more than one file. The path of a FILE is
truncated if necessary (first 6 char.s, ..., last 25 char.s)
- the TYPE in a report line is the ASCII value truncated to 37
char.s starting in column 8 (control char.s replaced by ?) -
- a TYPE starting in column 7 with x is a hex. translation for
unknown binary values (e.g. not ASCII or missing MVMT count)
- 123456789, possible TAGs (normally columns 1..7):
ASCII: valid ASCII .TYPE, i.e. not part of a MVMT EA
ASCII? dito, but invalid length (maybe use REPAIR)
ASCII= dito, REDUCEd (was MVMT) or REPAIRed (length)
MVMT+: valid ASCII in MVMT .TYPE EA
MVMT+? dito, but invalid length (maybe try REPAIR)
x???? x neither ASCII nor MVMT, REPAIR would erase EA
xFFFE x e.g. xFFFE (EAT BINARY) is not okay for .TYPE
m???? x non-ASCII in MVMT, REPAIR would erase MVMT EA
mFFFE x e.g. mFFFE (hex. value follows x in column 7)
MVMT? x MVMT too short, upto 3 hex. bytes following x
locked REMOVE, REPAIR, or REDUCE failed (OS/2 rc 32)
erased REMOVEd, old TYPE not shown, only the COUNTER
MVMT n summary of MVMT EAs with n item(s), examples:
MVMT 1 item(s) .............. 7 (can be REDUCEd)
MVMT 1 item(s) in CP 861 .... 3 (codepage not 0)
MVMT 2 item(s) ............. 14 (=> irreducible)
missed n found only k of n + k MVMT items, REPAIR does not
yet handle this or other "irreducible" cases
error x remaining hex. data after analyzing all items
error x00 e.g. trailing NUL after otherwise valid MVMT, in
"reducible" cases REDUCE would get rid of the NUL
n ???? n-th void (length 0) ASCII value (overlaying tag)
1 CII: e.g. 1st void value overlaying tag ASCII:
2 MT+: e.g. 2nd void value overlaying tag MVMT+:
(???): n-th (???) value of .TYPE matched by argument
(001): e.g. 1st found ASCII or MVMT .TYPE value
(002)? e.g. 2nd found value (? in column 6: bad length)
- to sort a report by type values simply use columns 8 upto 44
Okay, the header info about the report fomat are very obscure without an actual report, therefore try CHECKTYP.cmd without an argument first. CHECKTYP.cmd then creates CHECKTYP.tmp in your TMP directory, and if this file isn't obvious (most of it should be obvious), then consult the header info again.
Like CHECKEAS.cmd unique combinations of SEA .TYPE and EA type are directly identified in the report. Otherwise you only find a counter in the report, with one infamous exception: All occurences of empty (length 0) EAT_ASCII strings are treated as unique, i.e. matching no argument.
To find all files corresponding to other dubious .TYPE values simply specify the value as argument (case insensitive), CHECKTYP then treats these files as unique, bypassing its counter summary in the report for other .TYPE values found more than once.
Finally the arguments REDUCE, REPAIR, and REMOVE can be used to REDUCE EAT_MVMT without codepage (0) and one EAT_ASCII to a simple EAT_ASCII, REPAIR simple .TYPE problems like invalid lengths or spurious trailing NUL bytes, or REMOVE all .TYPE EAs created by Netscape for experimental MIME types (pattern */x-*).
CHECKHLP.cmd header as found in rxos2eas.zip:
OS/2 REXX: identify all *.HLP files setting a .TYPE attribute, old .TYPE values can be kept (interactive), for unknown *.HLP files you can select "text/plain", "Binary Data", or skip it - human readable "text/plain" is _not_ necessarily unstructured. Ignore NOTREADY errors, read access failed, nothing happens... If write access (to modify EAs) fails, you can try once again: probably you were just looking at the file in another session. XEAT() error 1 means "almost okay" (one trailing NUL ignored). XEAT() error 13 is serious (unexpected structure of EA .TYPE). Other XEAT errors are just the result of SysGetEA or SysPutEA. Press X, ESC, F3, or Alt-F4 (PM: CANCEL) to abort this script after errors (or in any other dialogue or PM RxMessageBox). Press Y, ENTER, or N (PM: YES or NO) to continue after errors. For details see "select when ..." in procedure DOIT, maybe add a type for Norton Guide, if you have an application for it, or replace types "QuickHelp" / "Win HLP file" / "OS/2 HLP file" - these are my own inventions (with corresponding applications, e.g. ViewHelp and/or NewView associated with "OS/2 HLP file"). BTW, I found an OS/S QuickHelp in the DDK (device driver kit). I am unsure about *.HLP files starting with magic header 'IS': maybe replace "Binary Data" by a .TYPE associated with XVIEW ?
CHECKHLP.cmd uses procedure XEAT also contained in rexxtrap.cmd (40 KB), see the REXXTRAP manual entry for XEAT. It's a simple way to get (SysGetEA ) or put (SysPutEA ) EA .TYPE into or from a REXX stem variable, hiding the details of EAT_MVMT vs. EAT_ASCII. Please note that CHECKHLP.cmd silently ignores type Reserved based on the following observations.
RESERVED.cmd removes a specified .TYPE EA from all files on all disks. Use it to clean up the "Reserved" mess created by the WPS or any other bogus type found by CHECKTYP.cmd. This script is a quick hack asking no questions, call it in a text window (VIO), I didn't add the overhead necessary for PM sessions.
EADELETE.cmd removes a specified EA from all files on all disks. This script is more friendly than its name, you can use it in a PM session, and it asks for a confirmation for each file with the specified EA. That's another way to find all files with any given EA. In theory you could list and remove a SEA like .PREVCLASS, and in practice I did this on my Warp 3 system, but for Warp 4 this would be a rather stupid idea. Just for info, here's a sorted list of EAs found by CHECKEAS on my system:
MVMT .APPTYPE ............. 130 BINARY .APPTYPE ............. 321 MVMT .ASSOCTABLE .......... 7 BINARY .CHECKSUM ............ 136 BINARY .CLASSINFO ........... 2649 MVMT .COMMENTS ............ 120 ASCII .EXPAND .............. 7 ASCII .EXPANDHARDWIRED ..... 3 MVMT .HISTORY ............. 109 ASCII .HISTORY ............. 2 ICON .ICON ................ 945 ICON .ICON1 ............... 339 BINARY .ICONPOS ............. 806 MVMT .KEYPHRASES .......... 111 ASCII .LONGNAME ............ 992 ASCII .PPDIMPORTING ........ 3 ASCII .SUBJECT ............. 137 MVMT .TYPE ................ 143 ASCII .TYPE ................ 2555 ASCII .VERSION ............. 11 MVMT .VERSION ............. 211 MVMT DATA.1 ............... E:\installed\gerfaq\SetVio.CMD MVMT DATA.2 ............... E:\installed\gerfaq\SetVio.CMD BINARY GRPHFILEINFO ......... 4 MVMT IBMLT.THUMBNAIL ...... 145 ASCII OPTIONALDRIVERFILES .. 3 MVMT OPTIONALDRIVERFILES .. 5 ASCII REQUIREDDRIVERFILES .. 3 MVMT REQUIREDDRIVERFILES .. 5 n/a REXX.LITERALPOOL ..... 261 0xEA60 REXX.METACONTROL ..... 261 0x10B8 REXX.PROGRAMDATA ..... 6 0x0000 REXX.TOKENSIMAGE ..... 261 n/a REXX.VARIABLEBUF ..... 261 ASCII VENDORNAME ........... 3 MVMT VENDORNAME ........... 4
Last update: 25 Jul 2006 23:00 by F.Ellermann