said:
>
> Correct. We already know it is difficult to prevent EA DATA. SF from
> being created. This means the obvious solution is to find the easiest way
> to delete it.
Yes, although I believe (but can't prove yet) that it will need to be renamed
before it is deleted. In one previous, but less well documented experiment
that I did for myself, I believe I did a simple delete in Win98 and the player
still locked up forcing a reformat. I believe the file left as a directory
entry but marked as a deleted file will still lock up the device.
> >TEST.TXT is not shown. I right click and click Rescan on the menu but it
> >still doesn't show. I double click on another drive and re-double click
> >F: and TEST.TXT appears in addition to the MP3 and the EA DATA. SF file.
> >This is not the behavior I expect from FM/2 but it being a new install
> >and I a new user, I chalk it up to my lack of familiarity with it.
>
> If the file exists on the drive, fm/2 should show it, unless you have
> configured the filters to not show it. We can review this a Saturday's
> meeting just to be sure it is not an fm/2 defect. You might want to try
> the v3.04 pre-release at
>
> <http://home.earthlink.net/~steve53/MarkKimesTools>
Filters we not configured other than what came by default. I was quite precise
in my description because of the need to diagnose my current problem. I
reported what I perceived as unexpected behavior by the program - I wouldn't
have intended for it to work that way if it were my program. Of course, I
didn't create it and it may be working as intended. However, if it is not
intended to work this way, then I believe it to be a defect. I'll try the 3.04
pre-release next dianostic session.
> >9) At this point, I pretty much recognize that I'm stuck. At best, I
> >need to rename the EA DATA. SF so that it has no non-standard characters
> >in its filename and then delete it to allow the MP3 player to work again.
>
> Correct. This is what I said you needed to do in my last reply.
Well, you said one would "use EAUTIL to strip all the EAs, a file manager to
delete "WP ROOT. SF" and dfsee to delete EA DATA. SF"". 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. In any case, I don't
believe simple file delete is sufficient for either file. For those not
familiar, IIRC, those are not spaces in the file names but an non-printing
ASCII character whose number I can't recall. You can still delete the WPS file
with a "DEL WP?ROOT.?SF" command if you've remove the attributes but DEL "WP
ROOT. SF" will not work if you've used spaces in the file name. Someone,
please correct me if I'm wrong but I thought I remember reading that a long
while back.
> >Every attempt to address the EA DATA. SF file is met with an error
> >similar to the one that is shown when "RENAME" in FM/2 is tried: "Rename
> >failed. Module: worker.c, Line number: 946, OS/2 error 32, Class:
> >Resource or data locked, action: Delay and retry. Device locked by
> >another process." All command-line attempts to delete the file also fail
> >(even after properly executing an "attrib -r -s -h *.*" command).
>
> Correct. This all entirely expected. Anyone who has used OS/2 for more
> than a little while should be entirely familiar with behavior and
> understand why it occurs. If they have forgotten, it's probably time for
> a bit of remedial work with Google.
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.
> >10) Trying to format the drive (right click the drive object and
> >clicking :"Format") causes the entire computer to lock up.
>
> From where? Fm/2 or the Desktop?
From the desktop.
> >Sorry for the long email but I get the impression that folks don't
> >believe me when they say the EA DATA. SF shouldn't be there or appear.
>
> Recall that I never said that. :-) I outlined a procedure that would
> allow you to safely get rid of it.
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's
only WP ROOT. SF doesn't get created. Only DOS COPY appears to prevent EA
creation but even this may not be true. My batch file work strips the EAs on
the source files before the copy.
> The utility Tom found was written by Veit, so I would be somewhat
> surprised if it did not work.
>
> The procedure you need to use to maintain the drive so that it does not
> lock up the player is
>
> - use whatever you want to drag and drop files
>
> There's no need to worry about EAs at this time becuase you are smart
> enough to delete them and EA DATA. SF before putting the drive in the mp3
> player
>
> When you want to put the drive in the mp3 player
>
> - click on the Desktop object labeled
>
> "Prepare drive for mp3 player"
>
> This object will runs a simple 4os2 script that does
>
> for /r %X (x:\*) eautil %x nul /s
> r_eadata x:
A couple of questions on this. It needs to remove WP DATA. SF too in case WPS
has been used. So maybe I should include the following two lines:
attrib -r -s -h x:\WP?ROOT.?SF
del x:\WP?ROOT.?SF
I did a help for at a command line and didn't see the /r CL argument. Does
that mean recurse? Otherwise, I can't be sure beforehand where all the
transfer files have been placed. If this doesn't recurse, I need to process
all existing directories or else, not all directories may be worked.
> This assumes your flash drive is mounted as x:
>
> You can ignore the comment in the r_eadata docs regarding chkdsk. Since
> the EAs have already been deleted, the drive should be clean after
> r_eadata deletes EA DATA. SF.
By the way, what is the upshot of deleting EA DATA. SF when files with EAs have
been placed on the drive. Is there any other risk other than the loss of all
EAs on that volume? Can I avoid using eautil to strip the EA's and just delete
the EA file, since it is FAT?
> > If for some reason r_eadata does not do the job, dfsee can be programming
> to do the job.
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.
> 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 [ 17 |
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.
