Printable View
For the first time ever, I have run across needed files which have extended
attributes in OS/2 that need to be processed in a DOS-VDM. Gee, you can't even
copy the files at a DOS-VDM command prompt! Nor even open them with any
DOS-VDM application.
Is there any solution to this which can be used to convert the file to remove
the dependency on the EA regime?
--
--> Sleep well; OS2's still awake! ;)
Mike Luther
Hi Mike,
[color=blue]
> For the first time ever, I have run across needed files which have extended
> attributes in OS/2 that need to be processed in a DOS-VDM. Gee, you can't even
> copy the files at a DOS-VDM command prompt! Nor even open them with any
> DOS-VDM application.
>
> Is there any solution to this which can be used to convert the file to remove
> the dependency on the EA regime?[/color]
Not too sure as I have never done it myself, however OS/2 comes with
EAUTIL.EXE (in x:\OS2) that allows for the removal and addition of
EA's to files. From the Help -
Allows you to split (save) extended attributes from a file and then
rejoin the extended attributes to the file.
Have you looked at that?
Cheers.......................pk.
--
Peter from Auckland.
[A complimentary Cc of this posting was sent to
Mike Luther
<mike.luther@ziplog.com>], who wrote in article <4876c7c1$0$4030$bbae4d71@news.suddenlink.net>:[color=blue]
> For the first time ever, I have run across needed files which have extended
> attributes in OS/2 that need to be processed in a DOS-VDM. Gee, you can't even
> copy the files at a DOS-VDM command prompt! Nor even open them with any
> DOS-VDM application.
>
> Is there any solution to this which can be used to convert the file to remove
> the dependency on the EA regime?[/color]
There is no dependency:
In DOS-VDM (with 4dos):
I:\EMX.ADD\DLL>copy btermcap.dll x-o /b
i:\emx.add\dll\btermcap.dll => i:\emx.add\dll\x-o
1 file(s) copied
In OS/2 window:
I:\emx.add\dll>dir btermcap.dll x-o
11-21-96 21:53 7,342 49 btermcap.dll
7,342 bytes in 1 file and 0 dirs 7,680 bytes allocated
2,208,229,888 bytes free
Volume in drive I is PROGRAMS Serial number is A9FA:8815
Directory of I:\emx.add\dll\x-o
11-21-96 21:53 7,342 49 x-o
7,342 bytes in 1 file and 0 dirs 7,680 bytes allocated
[shortened a little]
I see SOME (?) applications (Norton Commander) which refuse to open the
file; but apparently, TYPE of 4dos works.
Hope this helps,
Ilya
Interesting information Peter!
Peter wrote:
[color=blue]
> Hi Mike,
>
> Not too sure as I have never done it myself, however OS/2 comes with
> EAUTIL.EXE (in x:\OS2) that allows for the removal and addition of
> EA's to files. From the Help -
>
> Allows you to split (save) extended attributes from a file and then
> rejoin the extended attributes to the file.
>
> Have you looked at that?
>
> Cheers.......................pk.[/color]
I just did based on your suggestion! After heading the OS/2 help for it from a
'help eautil' command, I used an OS/2 command window session to copy two of
these files across PEERLAN to a test system. That worked. I then copied the
two files to a test subdirectory on a different partition. As expected, DOS
can't copy them, nor work with them in the test directory.
I then discovered, the the EAUTIL.EXE in either Warp 4 or MCP2 cannot handle
the "*" file command global operation for the two files. You actually have to
explicitly use the actual file name to use the tool, which does, in my case,
create an \EAS subdirectory for the separated extended attributes for each
file, coded as very specific to that same file name in the \EAS subdirectory.
At that point, I could work with these files with DOS.
OK, next question. After working with them, modifying them perhaps, or copying
them to another place on the system, can I delete the EA stripped files,
leaving the \EAS extended attribute copies of these files still there? What
might happen to possible corruption of the Desktop after that? I used UNIMAINT
to test for this. No found Desktop corruption.
Further, I then deleted the \EAS files and subdirectory. Checked again with
UNIMAINT for corruption. Nope. Clean system.
OK .. this might help solve my problem. But not at all home yet. What do you
do with a more or less infinite set of file names that all have to be handled
by the utility on a name by name basis?
GRRRRRR .....
--
--> Sleep well; OS2's still awake! ;)
Mike Luther
On Fri, 11 Jul 2008 16:21:35 UTC, Mike Luther <mike.luther@ziplog.com>
wrote:
[color=blue]
> OK .. this might help solve my problem. But not at all home yet. What do you
> do with a more or less infinite set of file names that all have to be handled
> by the utility on a name by name basis?[/color]
for %x in (*) do eautil %x /s
Been using it for literally years.
Thank you!
Bob Eager wrote:[color=blue]
> On Fri, 11 Jul 2008 16:21:35 UTC, Mike Luther <mike.luther@ziplog.com>
> wrote:
>[color=green]
>> OK .. this might help solve my problem. But not at all home yet. What do you
>> do with a more or less infinite set of file names that all have to be handled
>> by the utility on a name by name basis?[/color]
>
> for %x in (*) do eautil %x /s
>
> Been using it for literally years.[/color]
We're talking here about Rexx code for the .CMD file, correct? If so I think I
understand now how to solve this hurdle. Then after the above and you finish
doing what is needed, you just do a delete for all the files in the \EAS
directory it created?
Thanks!
--
--> Sleep well; OS2's still awake! ;)
Mike Luther
Hi Mike,
[color=blue]
> OK, next question. After working with them, modifying them perhaps, or copying
> them to another place on the system, can I delete the EA stripped files,
> leaving the \EAS extended attribute copies of these files still there?[/color]
Yes, an OS/2 file with EA's is very similar to the old MAC OS form of
"Data and Resource forks" for its files. There is no DIRECT link
between the file and the EA's, other than the Application that wrote
them and expects to be able to read them back. To everything else,
data is just data and can be individually handled.
Consider this, if you write a short OS/2 REXX Script, then BEFORE you
run it for the first time, only the FILE will exist. When this file is
executed, REXX creates the "P" code (pre-compiled ???) version of the
script and stores that in EA's, so subsequent executions of the script
run from the "P" code and are thus faster. If the "P" code version is
larger than 64KB, then it does NOT save it (it wont fit into an EA)
but then "P" code is generated each time the script is executed. You
can shorten this time down by using REXXC to "Compile" a large Rexx
script that gets stored as a .CMD file itself, but it is in "P" code
format, so it runs faster each time. Several of my larger Rexx Scripts
to do this.
The PM uses EA's itself, but then PM is really just another
application running on OS/2. It's also worth noting that OS/2 ZIP will
preserve EA's if you unzip the file in an OS/2 environment, but not if
you do it on DOS or another OS that does not understand them.
[color=blue]
> What
> might happen to possible corruption of the Desktop after that? I used UNIMAINT
> to test for this. No found Desktop corruption.[/color]
EA's are not system dependant (except for System files that use them).
[color=blue]
> Further, I then deleted the \EAS files and subdirectory. Checked again with
> UNIMAINT for corruption. Nope. Clean system.[/color]
As it should be......;-)
[color=blue]
> OK .. this might help solve my problem. But not at all home yet. What do you
> do with a more or less infinite set of file names that all have to be handled
> by the utility on a name by name basis?[/color]
FOR that one you need other help.....;-) I will leave that to the
other reply.
Cheers.................pk.
--
Peter from Auckland.
On Fri, 11 Jul 2008 18:36:09 UTC, Mike Luther <mike.luther@ziplog.com>
wrote:
[color=blue]
> Thank you!
>
> Bob Eager wrote:[color=green]
> > On Fri, 11 Jul 2008 16:21:35 UTC, Mike Luther <mike.luther@ziplog.com>
> > wrote:
> >[color=darkred]
> >> OK .. this might help solve my problem. But not at all home yet. What do you
> >> do with a more or less infinite set of file names that all have to be handled
> >> by the utility on a name by name basis?[/color]
> >
> > for %x in (*) do eautil %x /s
> >
> > Been using it for literally years.[/color]
>
> We're talking here about Rexx code for the .CMD file, correct?[/color]
Not REXX, just ordinary commands.
[color=blue]
> If so I think I
> understand now how to solve this hurdle. Then after the above and you finish
> doing what is needed, you just do a delete for all the files in the \EAS
> directory it created?[/color]
del \eas /n
On 12 Jul 2008 09:29:17 +1200, Peter <SOMEONE@orcon.net.nz> wrote:
[color=blue]
> The PM uses EA's itself[/color]
No it doesn't.
[color=blue]
> but then PM is really just another application running on OS/2.[/color]
No it isn't.
You probably mean the WPS. The WPS is not PM and PM is not the WPS.
The WPS is just another PM application.
[color=blue]
> EA's are not system dependant[/color]
They are actually. The stuff the WPS stores in the EAs contains the object
handle, which is not transferrable between systems in any meaningful way.
Aha! Success with one little change!
Bob Eager wrote:
[color=blue]
> for %x in (*) do eautil %x /s
>
> Been using it for literally years.
> Not REXX, just ordinary commands.[/color]
Slight error, but that fixed it works fine as a batch file line.
for %xx in (*) do eautil /s %%x
The variable parameter has to follow the eautil /s command! Thank you for
teaching me more about OS/2.
--
--> Sleep well; OS2's still awake! ;)
Mike Luther
On Sat, 12 Jul 2008 02:50:56 UTC, Mike Luther <mike.luther@ziplog.com>
wrote:
[color=blue]
> Aha! Success with one little change!
>
> Bob Eager wrote:
>[color=green]
> > for %x in (*) do eautil %x /s
> >
> > Been using it for literally years.
> > Not REXX, just ordinary commands.[/color]
>
> Slight error, but that fixed it works fine as a batch file line.
>
> for %xx in (*) do eautil /s %%x[/color]
Not an error at all. I wasn't providing it for a batch filem, but as a
typed command. For a batch file, one does have to double the % signs.
[color=blue]
> The variable parameter has to follow the eautil /s command![/color]
It doesn't.
Interesting and please, I'm not being critical here Bob!
Bob Eager wrote:
[color=blue][color=green]
>> Bob Eager wrote:[/color]
>
> Not an error at all. I wasn't providing it for a batch filem, but as a
> typed command. For a batch file, one does have to double the % signs.
>[color=green]
>> The variable parameter has to follow the eautil /s command![/color]
>
> It doesn't.[/color]
Weird, it does here! In every case on three different boxes, two MCP2 and one
Warp 4 box involved in this issue, if I don't use the order I suggested, I get
a complete SYS error for OS/2 which is an 'unexpected variable' error:
SYS1079 x was expected at this time
SYS1079: *** was unexpected at this time.
EXPLANATION: The command is missing required keywords.
ACTION: Retry the command correctly.
If I simply reverse the order as I suggested, the SYS1079 error goes away. I
just did this again to recover the above error to copy into the clipboard and
paste it here above. It took me an hour or so to discover this. In my case it
involves the %%x format for the command file use. I dunno about the hand entry
command line issue. Maybe it doesn't matter there.
And please, I'm not being critical here Bob. You're work is far to valuable
for this to be taken that way.
--
--> Sleep well; OS2's still awake! ;)
Mike Luther
On Sat, 12 Jul 2008 14:40:18 UTC, Mike Luther <mike.luther@ziplog.com>
wrote:
[color=blue]
> Interesting and please, I'm not being critical here Bob!
>
> Bob Eager wrote:
>[color=green][color=darkred]
> >> Bob Eager wrote:[/color]
> >
> > Not an error at all. I wasn't providing it for a batch filem, but as a
> > typed command. For a batch file, one does have to double the % signs.
> >[color=darkred]
> >> The variable parameter has to follow the eautil /s command![/color]
> >
> > It doesn't.[/color]
>
> Weird, it does here! In every case on three different boxes, two MCP2 and one
> Warp 4 box involved in this issue, if I don't use the order I suggested, I get
> a complete SYS error for OS/2 which is an 'unexpected variable' error:
>
> SYS1079 x was expected at this time
>
> SYS1079: *** was unexpected at this time.
> EXPLANATION: The command is missing required keywords.
> ACTION: Retry the command correctly.
>
> If I simply reverse the order as I suggested, the SYS1079 error goes away. I
> just did this again to recover the above error to copy into the clipboard and
> paste it here above. It took me an hour or so to discover this. In my case it
> involves the %%x format for the command file use. I dunno about the hand entry
> command line issue. Maybe it doesn't matter there.[/color]
Does it have something to do with spaces? See this:
-------------------------------------------------------------
[E]type z.cmd
for %%x in (*.txt) do eautil %%x /s
[E]z
[E]for %x in (*.txt) do eautil %x /s
[E]eautil order.txt /s
[E]eautil recorded.txt /s
[E]eautil todo.txt /s
-------------------------------------------------------------
That's cut and pasted from a window on 4.52.
The %% bit has been around since DOS 2.0. Because % is used to introduce
other stuff, it needs to be put twice to indicate a single %.