SCOUG Logo


Next Meeting: Sat, TBD
Meeting Directions


Be a Member
Join SCOUG

Navigation:


Help with Searching

20 Most Recent Documents
Search Archives
Index by date, title, author, category.


Features:

Mr. Know-It-All
Ink
Download!










SCOUG:

Home

Email Lists

SIGs (Internet, General Interest, Programming, Network, more..)

Online Chats

Business

Past Presentations

Credits

Submissions

Contact SCOUG

Copyright SCOUG



warp expowest
Pictures from Sept. 1999

The views expressed in articles on this site are those of their authors.

warptech
SCOUG was there!


Copyright 1998-2024, 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.

The Southern California OS/2 User Group
USA

SCOUG-HELP Mailing List Archives

Return to [ 12 | February | 2006 ]

<< Previous Message << >> Next Message >>


Date: Sun, 12 Feb 2006 14:12:09 PST8
From: "Michael Rakijas" <mrakijas@adelphia.net >
Reply-To: scoug-help@scoug.com
To: scoug-help@scoug.com
Subject: SCOUG-Help: Experiment #1 (Keeping hidden files off USB drive)

Okay, here is experiment #1, also known as "why it's so difficult to keep OS/2
(eCS in this case) hidden files off of USB drive." For those who haven't kept
up, here's the story so far: I'm trying to use OS/2 to manage music files
prior to copying to a portable MP3 player. The player behaves like a USB
flash-memory drive when connected to the computer. In theory, it is simply a
matter of copying MP3 files to the drive. In practice, the appearance of eCS
hidden files (WP ROOT. SF, EA ROOT. SF) causes the player to lock up and not
play, even though it shouldn't since the drive is supposed to act as a file
transfer device for non-MP3 files. It seems that deleting the files is not
sufficient since those hidden characters in the filename entries is enough to
lock up the player. I can only delete or rename the files in Win98 since WinXP
seems to preserve EAs and handles the EA DATA. SF file as a
locked-by-the-OS-or-another-process file that is not to be deleted. My current
mode of operation is having written a DOS batch file that first strips the EAs
and then uses the equivalent command line copy to get files copied in bunches
to individual folders. This mostly works but is tedious and the occasional
failure requires using the Win98 machine again to fix things up.

So, that is the introduction and here is the preamble. This is an eCS 1.2
(non-refresh) system which is using the stock USB drivers except for one thing.
After being unable to get the MP3 player's USB drive to be recognized by the
OS, I had to replace the USBD.SYS driver with the one from
http://hobbes.nmsu.edu/pub/os2/apps/mmedia/music/mmportv1.zip. I don't know if
this is fool proof but it permits using the above described batch file
procedure to transfer files to the drive without creating either of the hidden
files on it. From an earlier discussion of this topic, I installed FM/2 v3.03
on the machine to conduct the described experiment to verify what I believe was
happening. The results of the experiment below should begin to give you an
ideas why this is problem is so difficult to deal with. Finally, the last
thing you need to know is that I start this experiment with the USB drive as a
freshly formatted 1 GB drive on the Win98 machine to give a uniform and
unquestionable starting point. Okay, so here are the steps:

1) Plugged the drive in to the eCS computer. Double clicked the "Refresh
Removable Media" and the drive appears properly as drive F: FM/2 confirms the
drive is empty.

2) I find an MP3 music file on the machine to use as a test case. Since the
player/flash drive is formatted FAT, I make sure the test MP3 file is 8.3 file
but it also appears to have EAs attached to it, according to FM/2. This makes
it a good test case.

3) Using FM/2, I copy (drag and drop) the file to the drive. FM/2 confirms the
copy and seems to indicate that only the file has been copied.

4) To test the player, I right click the drive object and click eject. I
physically disconnect the drive and try the player. It locks up. When this
happens, I must pull the battery to get the device to reset and I do so. I
replace the battery.

5) I reconnect the drive to the computer and activate "Refresh Removable
Media". I look at the device using FM/2 which now shows the presence of EA
DATA. SF in addition to the MP3 file. It seems like it shouldn't be present
but no matter, the real desire is to remove it once it is present to handle
when this happens inadvertantly.

6) I open a command line and execute the following on the MP3 file: EAUTIL
FILE.MP3 TEST.TXT /S. DIR confirms the presence of a file TEST.TXT.

7) I return to the still open FM/2 which was still showing the drive when it
was last used. I double click on the drive again to refresh and 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.

8) I use FM/2 to delete the TEST.TXT file. This leaves two files on the
drive: the MP3 file and the EA DATA. SF file. The MP3 file no longer has any
EA's attached to it (indicated by a "0" in the EA column of the file listing in
FM/2).

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. 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).

10) Trying to format the drive (right click the drive object and clicking
:"Format") causes the entire computer to lock up.

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. I think this
example set should address a number of questions of "Why don't you try this?".
I still welcome suggestions but please consider the above examples: one of the
above examples will probably show why your suggestion may not work.

-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 [ 12 | 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.