said:
>
> >Yes, although I believe (but can't prove yet) that it will need to be
> >renamed before it is deleted.
>
> Yes, I already have working code that does this. Talk is cheap. I prefer
> to have working tools. You will probably get to be the test dummy once
> I'm reasonably sure it is bullet proof.
Asking for solutions is volunteering to be a guinea pig as far as I'm concerned.
> >I'm not sure
> >what dfsee does when deleting a file but I believe that if it does no
> >more than a conventional file delete, then it is insufficient.
>
> Since it is not insufficient, it obviously does more. For example, it can
> delete EA DATA. SF, which most folks find difficult or impossible when
> booted the eCS/OS2.
When I said insufficient, I meant it in terms of solving the problem with my
MP3 player. I have already witnessed a situation in which the file was deleted
(using Win98) in which the player still locked up. Thus, if I am correct, it
is insufficient to simply delete the file (i.e. mark the file name entry in the
FAT with the special 'deleted file' character). From this, it is impossible to
say that it is sufficient at this point, although DFSEE may do more. I haven't
tried it yet and if it doesn't fix the problem, then it is insufficient.
> YANRCC
>
> DFSee OS/2 7.15 : Executing: h 1fa
> Start sector LSN : 0x000001FA Size to display : 256 bytes
>
> -00000-
> 45 41 20 44 41 54 41 20 20 53 46 27 00 00 00 00 [EA DATA SF'....]
> -00010- 00 00 00 00 00 00 44 68 5f 27 ca 01 00 30 07 00
> [......Dh_'...0..]
>
> Try
>
> ren "WP ROOT. SF" WPXROOT.XSF
>
> and see what happens.
It does appear that the non-printing characters are spaces but this may very
well be the unexpected situation that the firmware writers hadn't anticipated
and is causing it to fail. Marking the initial character to signify 'deleted'
may not be enough.
> >Just trying to set the stage that deleting the EA DATA. SF file is not as
> >simple as removing offending attributes from the file and deleting it.
>
> Well it is unless you are booted to eCS/OS2.
I choose to interpret this not as a suggestion to change :-).
> >I don't believe I said you did. :-). Just in case someone thought that
> >using a file manager like FM/2 prevented both file's creation, it's not
> >true.
>
> It may be true, but we need to test it. Fm/2 has a feature known as drive
> flags that can suppress the creation of EAs on a drive. This may have the
> side effect of bypassing the creation of EA DATA. SF. We can test this on
> Saturday, maybe.
Since we didn't get to it today, if you can suggest to me where to look for
this capability, I'm willing to give it a shot when I get back.
> >Thanks. As I mentioned in my response to Tom, I'll be in Dallas starting
> >Sunday so I'll probably get to it next week.
>
> Have fun.
Thanks.
> Steven
-Rocky
=====================================================
To unsubscribe from this list, send an email message
to "steward@scoug.com". In the body of the message,
put the command "unsubscribe scoug-help".
For problems, contact the list owner at
"postmaster@scoug.com".
=====================================================
<< Previous Message <<
>> Next Message >>
Return to [ 18 |
February |
2006 ]
The Southern California OS/2 User Group
P.O. Box 26904
Santa Ana, CA 92799-6904, USA
Copyright 2001 the Southern California OS/2 User Group. ALL RIGHTS
RESERVED.
SCOUG, Warp Expo West, and Warpfest are trademarks of the Southern California OS/2 User Group.
OS/2, Workplace Shell, and IBM are registered trademarks of International
Business Machines Corporation.
All other trademarks remain the property of their respective owners.
