On Tue, 30 Nov 2004 00:37:02 UTC, Paul Ratcliffe wrote:

> Is anyone interested in having a fixed version of the ISOFS file system?

What does not work?

> The patch file is very small - you'd have to change fewer than a dozen
> lines in a total of 3 files.
> The source is downloadable from here:
> http://www.os2world.com/cdwriting/isofs/isofsmain.htm
> and I will mail the patch file to anyone who can do a build.

I am set up for it and just tried to compile it with GCC322. Worked
nicely. Static linking (to not be dependent on gcc322.dll and
libc05.dll) and then lxlite gives even smaller binaries than in the
original version...

But, did you ask the author/porter (Chris)? That should be the first
route... Anyway, feel free to send the patch to my Reply-to address.
--
Greetings,
Peter.

On 30 Nov 2004 10:16:19 GMT, Peter Weilbacher wrote:

> On Tue, 30 Nov 2004 00:37:02 UTC, Paul Ratcliffe wrote:
>
>> Is anyone interested in having a fixed version of the ISOFS file system?
>
> What does not work?

1) The daemon locks the .ISO file open in certain circumstances.
2) There are files missing from directories as displayed by the file
system which are there on the .ISO.
3) Cosmetic errors on MTNISOFS.

> I am set up for it and just tried to compile it with GCC322. Worked
> nicely. Static linking (to not be dependent on gcc322.dll and
> libc05.dll) and then lxlite gives even smaller binaries than in the
> original version...

Excellent. The parts that need rebuilding are MNTISOFS.EXE and ISOFSDMN.EXE,
but if the other bits can be done, that'd be good.

> But, did you ask the author/porter (Chris)? That should be the first
> route...

I did. No response after a week, hence the post here.

> Anyway, feel free to send the patch to my Reply-to address.

Will do. Thanks!

[A complimentary Cc of this posting was NOT [per weedlist] sent to
Paul Ratcliffe
], who wrote in article :
> 1) The daemon locks the .ISO file open in certain circumstances.

Is --quit working now?

> 2) There are files missing from directories as displayed by the file
> system which are there on the .ISO.

More details, please. Are you supporting images without Joliet? Are
you supporting pure iso9660-view (sp?) on an image with Joliet? What
about broken Joliet written by XP (which has "\0" instead of " " at
some position in the header; see isoinfo source: it prints a warning
in such a case)?

> Excellent. The parts that need rebuilding are MNTISOFS.EXE and ISOFSDMN.EXE,
> but if the other bits can be done, that'd be good.

Is stubfsd.ifs supporting large file API? What about ISOFSDMN?

Thanks,
Ilya

P.S. It does not make sense to say "I have a patch, but I can't
compile it". Testing and other QA takes 90% of the time when
patching.

Paul Ratcliffe wrote:

>Is anyone interested in having a fixed version of the ISOFS file system?
>This is something that allows you to mount a .ISO file and access the files
>on it directly via a drive letter, exactly as you would do if you'd burnt
>it onto a CD.
>
>I have fixed the annoying bugs in the 0.2.1 version, but am unable to build
>it as I don't do EMX/GCC/DMAKE/BASH/SED/'whatever the f*** else is required
>to compile a simple program'.
>
>
>
Maybe you should discover UX2BS - it takes all the pain out of compiling
not only simple programs but also complicated ones like Perl. All you
need to do is run a very simple batchfile which will pull down
everything you need and install it, then proceed to build 'whatever the
f*** else is required'.

I'm collecting every patch that I've ever come across with the aim of
providing a system which will everyone to build whatever apps they want,
simply by running 'build appname'


>Is anyone who is set up for all this Unixy junk willing to do a build?
>The patch file is very small - you'd have to change fewer than a dozen
>lines in a total of 3 files.
>The source is downloadable from here:
> http://www.os2world.com/cdwriting/isofs/isofsmain.htm
>and I will mail the patch file to anyone who can do a build.
>
>
>
I'd like a copy of the patch at some time point if that's OK just to
ensure that UX2BS can use it.

My real email address is guessable from the one you see.


>Thanks,
>Paul
>
>

On Tue, 30 Nov 2004 19:05:31 +0000 (UTC), Ilya Zakharevich
wrote:

>], who wrote in article :
>> 1) The daemon locks the .ISO file open in certain circumstances.
>
> Is --quit working now?

No. I didn't know it was broken. Heck, I didn't know it existed until I
just looked at the source again. I guess a process killer will suffice,
but who knows. Anyway, the major reasons for killing it have gone away.

>> 2) There are files missing from directories as displayed by the file
>> system which are there on the .ISO.
>
> More details, please.

The directory records are stored in 2048 byte chunks. The last record
in the chunk was more often than not being ignored because of a bug in
calculating where the end of the buffer was relative to the current
position and whether another record could be fitted in.

> Are you supporting images without Joliet?

No.

> Are you supporting pure iso9660-view (sp?) on an image with Joliet?

No.

> What about broken Joliet written by XP (which has "\0" instead of " " at
> some position in the header; see isoinfo source: it prints a warning
> in such a case)?

What about them? If Mickeysoft can't write proper images that is their
problem. So, no.

> Is stubfsd.ifs supporting large file API? What about ISOFSDMN?

No and no. I am sure if you would like to put some development effort
into any of this, it could be achieved, but somehow I doubt you will.
All I said was that I had fixed the obvious and annoying bugs, which made
the thing virtually unusable for any practical purpose. Now it is usable
for a lot of purposes. I never said it was going to be perfect - it would
need a complete rewrite IMHO.

> P.S. It does not make sense to say "I have a patch, but I can't
> compile it".

Actually it does, seeing as one of the problems was an obvious boundary
condition error. Another was cosmetic.
You can spot many a bug by simple inspection of the code. You don't
necessarily have to be able to compile it to spot a missing fclose()
for example, which was the other bug.

FWIW, I hacked away at the included (but not used) isoinfo.c file until it
compiled with VAC++. A lot of the functionality was lost but I hard coded
some things and it gave me enough to go on. Doing this does not mean I am
in a position to build the real daemon code.

> Testing and other QA takes 90% of the time when patching.

I am not your grandmother, nor do I wish to be taught how to suck eggs,
OK?
Next time, you can do the damned work.

On Tue, 30 Nov 2004 20:07:30 +0000, jp wrote:

> Maybe you should discover UX2BS - it takes all the pain out of compiling
> not only simple programs but also complicated ones like Perl.

Maybe, but life's too short. I don't know why people feel the need to
make things so damned complicated in the first place.
I have no idea what the Makefile does or why it needs Bash and Sed for
example. It is, after all, only compiling and linking and why can you not
do that with the tools that come with the compiler?
If the compiler doesn't come with the tools to build what is (in this case)
really a very simple utility program, then it isn't worth having IMHO.
This is why I cannot be bothered with GCC, EMX or whatever else and why
I stick with VAC++, which also has documentation in a usable format.

> All you
> need to do is run a very simple batchfile which will pull down
> everything you need and install it, then proceed to build 'whatever the
> f*** else is required'.

Hmm, I'll believe it when I see it.

> I'm collecting every patch that I've ever come across with the aim of
> providing a system which will everyone to build whatever apps they want,
> simply by running 'build appname'

Aargh. See above.

> I'd like a copy of the patch at some time point if that's OK just to
> ensure that UX2BS can use it.

On its way.

On Wed, 1 Dec 2004 02:01:42 UTC Paul Ratcliffe
wrote:

> Maybe, but life's too short. I don't know why people feel the need to
> make things so damned complicated in the first place.
> I have no idea what the Makefile does or why it needs Bash and Sed for
> example. It is, after all, only compiling and linking and why can you not
> do that with the tools that come with the compiler?
> If the compiler doesn't come with the tools to build what is (in this case)
> really a very simple utility program, then it isn't worth having IMHO.
> This is why I cannot be bothered with GCC, EMX or whatever else and why
> I stick with VAC++, which also has documentation in a usable format.

To which I can only add a hearty AMEN! Trying to run a simple compile
on some of this crap means installing Python or some such, then
figuring out how to use the bloody tool that needs it, followed by
endless debugging of what went wrong - give me a makefile with the
dependencies identified and leave it up to me to fit it to MY system
without jumping thru hours of useless hoops that contribute NOTHING to
the resulting code.

--
Will Honea

[A complimentary Cc of this posting was NOT [per weedlist] sent to
Paul Ratcliffe
], who wrote in article :
> On Tue, 30 Nov 2004 19:05:31 +0000 (UTC), Ilya Zakharevich
> wrote:

> > Is --quit working now?
>
> No. I didn't know it was broken. Heck, I didn't know it existed until I
> just looked at the source again. I guess a process killer will suffice,
> but who knows. Anyway, the major reasons for killing it have gone away.

One major reason - probably; if the testing confirms it. There is
another: it uses EMX, and since it is usually started by RUN
statement, there is no way to update/debug EMX without rebooting.

> > More details, please.
>
> The directory records are stored in 2048 byte chunks. The last record
> in the chunk was more often than not being ignored because of a bug in
> calculating where the end of the buffer was relative to the current
> position and whether another record could be fitted in.

Thanks for an explanation; my (scarce) experiments lead me to a wrong
conclusion that it might have been that only Joliet-less stuff
contributed.

> > What about broken Joliet written by XP (which has "\0" instead of " " at
> > some position in the header; see isoinfo source: it prints a warning
> > in such a case)?
>
> What about them? If Mickeysoft can't write proper images that is their
> problem. So, no.

??? It is a problem of people who want to read these CDs, not of M$.

> > P.S. It does not make sense to say "I have a patch, but I can't
> > compile it".
>
> Actually it does, seeing as one of the problems was an obvious boundary
> condition error. Another was cosmetic.

In my experience, things are rarely what that look like on the first
sight. However, any particular case can contradict such a sweeping
generalization. ;-) I hope this one does...

Yours,
Ilya

On 1 Dec 2004 08:56:22 GMT, Will Honea wrote:

> On Wed, 1 Dec 2004 02:01:42 UTC Paul Ratcliffe
> wrote:
>
>> Maybe, but life's too short. I don't know why people feel the need to
>> make things so damned complicated in the first place.
>> I have no idea what the Makefile does or why it needs Bash and Sed for
>> example. It is, after all, only compiling and linking and why can you not
>> do that with the tools that come with the compiler?
>
> To which I can only add a hearty AMEN! Trying to run a simple compile
> on some of this crap means installing Python or some such, then
> figuring out how to use the bloody tool that needs it, followed by
> endless debugging of what went wrong - give me a makefile with the
> dependencies identified and leave it up to me to fit it to MY system
> without jumping thru hours of useless hoops that contribute NOTHING to
> the resulting code.

Exactly. I prefer to spend the time on fixing the code, not the damned
build system.

On Wed, 1 Dec 2004 20:41:42 +0000 (UTC), Ilya Zakharevich
wrote:

>> No. I didn't know it was broken. Heck, I didn't know it existed until I
>> just looked at the source again. I guess a process killer will suffice,
>> but who knows. Anyway, the major reasons for killing it have gone away.
>
> One major reason - probably; if the testing confirms it.

Testing Peter W's build proved pointless as it didn't work, so I had to
break down and fix the entire build system so it would run here.
Having thrown all the crap away, I find it was unnecessary anyway as it
now builds fine and much more simply, with no dependencies on half the
Unix packages in the world. Only GCC and GNU make required.

FWIW, a process killer does nasty things if you kill the daemon while
an image is mounted. Need some cleanup code in the daemon.

> There is another: it uses EMX, and since it is usually started by RUN
> statement, there is no way to update/debug EMX without rebooting.

Not any more. I'm building with the latest GCC and it will use static
runtime libraries. There will be no dependencies on anything not supplied
with the operating system.
In any case, how often do you update EMX? There hasn't been anything to
update for years.
Also, you can still kill things even if they are started with a RUN
statement.

>> The directory records are stored in 2048 byte chunks. The last record
>> in the chunk was more often than not being ignored because of a bug in
>> calculating where the end of the buffer was relative to the current
>> position and whether another record could be fitted in.
>
> Thanks for an explanation; my (scarce) experiments lead me to a wrong
> conclusion that it might have been that only Joliet-less stuff
> contributed.

Have looked at the code extensively, I can say that it is a pile of crap.
That is, it is based on Joerg Schiling's isoinfo.c source which is a pile
of crap. I don't know how nobody has noticed how buggy it is before.
It is badly written, hard to read, even harder to maintain and has sod
all in the way of error checking.
If this is how the rest of the Unix world writes code then God help them.

>> > What about broken Joliet written by XP (which has "\0" instead of " " at
>> > some position in the header; see isoinfo source: it prints a warning
>> > in such a case)?
>>
>> What about them? If Mickeysoft can't write proper images that is their
>> problem. So, no.
>
> ??? It is a problem of people who want to read these CDs, not of M$.

Have you got an exact reference? This is somewhat vague. FYI, the valid
Joliet sequences are "%/@", "%/C" and "%/E" each followed by a null.
Do you have a broken image you can send me the first part of for analysis?

> In my experience, things are rarely what that look like on the first
> sight. However, any particular case can contradict such a sweeping
> generalization. ;-) I hope this one does...

Case not proved one way or the other in this case, because I've now done
many many more changes.
I've resurrected the appalling isoinfo.c code and am using that as a test
bed for implementing non-Joliet images and High Sierra images, which is
working nicely. This code can now be implemented in the IFS.

Paul Ratcliffe wrote:

> Have looked at the code extensively, I can say that it is a pile of crap.
> That is, it is based on Joerg Schiling's isoinfo.c source which is a pile
> of crap. I don't know how nobody has noticed how buggy it is before.
> It is badly written, hard to read, even harder to maintain and has sod
> all in the way of error checking.
> If this is how the rest of the Unix world writes code then God help them.
>
Not the entire rest of the Unix world in general, but some people, yes.
I've seen some clean and well written code (lot of the Linux kernel code
for instance) and some incredibly badly written code as well (*cough*
mplayer *cough*). Just like with commerical programmers, there is no
requirement that open source programmers must be actually good. It's just
that with commercial code, only very few people get to see the mess


Michal

[A complimentary Cc of this posting was NOT [per weedlist] sent to
Paul Ratcliffe
], who wrote in article :
> > There is another: it uses EMX, and since it is usually started by RUN
> > statement, there is no way to update/debug EMX without rebooting.
>
> Not any more. I'm building with the latest GCC and it will use static
> runtime libraries. There will be no dependencies on anything not supplied
> with the operating system.
> In any case, how often do you update EMX?

It is quite often that to debug problems I need a debugging copy of EMX.

> Also, you can still kill things even if they are started with a RUN
> statement.

I do not think this works/worked with ISOFSDMN (sp???).

> That is, it is based on Joerg Schiling's isoinfo.c source which is a pile
> of crap. I don't know how nobody has noticed how buggy it is before.

In my experience the newer versions are much better (but I did not do
any extensive research).

> >> > What about broken Joliet written by XP (which has "\0" instead of " " at
> >> > some position in the header; see isoinfo source: it prints a warning
> >> > in such a case)?
> >>
> >> What about them? If Mickeysoft can't write proper images that is their
> >> problem. So, no.
> >
> > ??? It is a problem of people who want to read these CDs, not of M$.
>
> Have you got an exact reference?

I just created the CD "the OS way" on XP without any servicepack (I
think I just inserted a blank CD, and it either gave me a choice to
write it, or right-clicking on CD drive in "My computer" gave this
choice; it is very rare that I see XP...).

> This is somewhat vague. FYI, the valid
> Joliet sequences are "%/@", "%/C" and "%/E" each followed by a null.

OK, then it was followed by SPACE. It looks like I misplaced the
newer source isoinfo.c, but I expect one can find the warning by
looking for string ' ' (3 characters: TICK SPACE TICK; darn quoting hell...).

> Do you have a broken image you can send me the first part of for analysis?

I will try to find the actual CD. How many sectors do you think you
need? It contained about 1200 files...

> I've resurrected the appalling isoinfo.c code and am using that as a test
> bed for implementing non-Joliet images and High Sierra images, which is
> working nicely. This code can now be implemented in the IFS.

What I think will be very useful is to translate filenames to UTF-8
(and maybe even UTF-7 - the latter one is not supported by OS/2 API,
but both are trivial to implement in 10 lines of C). This way one can
read all the files on Joliet image no matter what (the price being
that the filenames may be not immediately readable) - unless the
translated name is longer than 260 chars...

Thanks,
Ilya

P.S. Would not it be easier to implement images the other way around:
by associating a drive letter with a file via some DMD, then let the
standard OS/2 mechanism recognize that the FS is ISO one? If
usbmsd.sys can create drives on a fly, why not do this?

Of course, a lot of advantages of ISOFS would be missing (like the
ability to switch the charset).

On Mon, 6 Dec 2004 22:38:00 +0000 (UTC), Ilya Zakharevich
wrote:

>> Also, you can still kill things even if they are started with a RUN
>> statement.
>
> I do not think this works/worked with ISOFSDMN (sp???).

It didn't for me on the old version. Haven't tried with the new version.
There is no reason why it shouldn't as far as I can see. Will have to
investigate.

>> That is, it is based on Joerg Schiling's isoinfo.c source which is a pile
>> of crap. I don't know how nobody has noticed how buggy it is before.
>
> In my experience the newer versions are much better (but I did not do
> any extensive research).

Where does one find the latest source? Google came up with version 1.24
which still has all the horrid code.

>> This is somewhat vague. FYI, the valid
>> Joliet sequences are "%/@", "%/C" and "%/E" each followed by a null.
>
> OK, then it was followed by SPACE. It looks like I misplaced the
> newer source isoinfo.c, but I expect one can find the warning by
> looking for string ' ' (3 characters: TICK SPACE TICK; darn quoting hell...).

Again, where do I find it?

> I will try to find the actual CD. How many sectors do you think you
> need? It contained about 1200 files...

Probably just the sector from offset 0x8800, but best to include say 8k
of data starting at offset 0x8000 to be sure.

> What I think will be very useful is to translate filenames to UTF-8
> (and maybe even UTF-7 - the latter one is not supported by OS/2 API,
> but both are trivial to implement in 10 lines of C). This way one can
> read all the files on Joliet image no matter what (the price being
> that the filenames may be not immediately readable) - unless the
> translated name is longer than 260 chars...

I know almost nothing about this character set business. The code already
includes unicode decoding. I know nothing about any OS/2 APIs regarding
this stuff.

> P.S. Would not it be easier to implement images the other way around:
> by associating a drive letter with a file via some DMD, then let the
> standard OS/2 mechanism recognize that the FS is ISO one?

I've no idea. Never written a DMD before. I'm not quite sure how you'd
associate drives with files anyway. An IFS is much easier, especially
as it's already written.

> If usbmsd.sys can create drives on a fly, why not do this?

How does it do this? And why doesn't it get rid of them afterwards?
I've never done anything with USB, but I plugged a compact flash card
from my camera in via an adapter the other day and was amazed to find
it worked. However, it doesn't give me a choice of drive letter and when
I unplug it, it doesn't go away, which causes problems.
Does anybody know what mechanisms are at work here?

The IFS way is much better for .ISOs IMHO.

> Of course, a lot of advantages of ISOFS would be missing (like the
> ability to switch the charset).

That's another reason not to do it then.

On Tue, 07 Dec 2004 00:38:50 GMT, Paul Ratcliffe
wrote:

>>> That is, it is based on Joerg Schiling's isoinfo.c source
>
> Where does one find the latest source? Google came up with version 1.24
> which still has all the horrid code.

I found it at ftp://ftp.berlios.de/pub/cdrecord
It has fixed the horrid bugs, but the code's even more of a mess now a
couple more features have been bolted on.

>> I will try to find the actual CD. How many sectors do you think you
>> need? It contained about 1200 files...
>
> Probably just the sector from offset 0x8800, but best to include say 8k
> of data starting at offset 0x8000 to be sure.

Forget it. I've added the 'space where the null should be' check.

On Tue, 7 Dec 2004 00:38:50 UTC, Paul Ratcliffe
wrote:

> > P.S. Would not it be easier to implement images the other way around:
> > by associating a drive letter with a file via some DMD, then let the
> > standard OS/2 mechanism recognize that the FS is ISO one?
>
> I've no idea. Never written a DMD before. I'm not quite sure how you'd
> associate drives with files anyway. An IFS is much easier, especially
> as it's already written.

Yes, I'd be tempted to go right down to the lowest level, and make a
'pseudocdrom.sys' driver. That could then connect to the file, and also
attach to the CDROM FSD. No need to understand any file formats then...

Paul Ratcliffe wrote:
> On Mon, 6 Dec 2004 22:38:00 +0000 (UTC), Ilya Zakharevich
> wrote:
>
>
>>>Also, you can still kill things even if they are started with a RUN
>>>statement.
>>
>>I do not think this works/worked with ISOFSDMN (sp???).
>
>
> It didn't for me on the old version. Haven't tried with the new version.
> There is no reason why it shouldn't as far as I can see. Will have to
> investigate.
>
>
>>>That is, it is based on Joerg Schiling's isoinfo.c source which is a pile
>>>of crap. I don't know how nobody has noticed how buggy it is before.
>>
>>In my experience the newer versions are much better (but I did not do
>>any extensive research).
>
>
> Where does one find the latest source? Google came up with version 1.24
> which still has all the horrid code.
>
>
>>>This is somewhat vague. FYI, the valid
>>>Joliet sequences are "%/@", "%/C" and "%/E" each followed by a null.
>>
>>OK, then it was followed by SPACE. It looks like I misplaced the
>>newer source isoinfo.c, but I expect one can find the warning by
>>looking for string ' ' (3 characters: TICK SPACE TICK; darn quoting hell...).
>
>
> Again, where do I find it?
>
>
>>I will try to find the actual CD. How many sectors do you think you
>>need? It contained about 1200 files...
>
>
> Probably just the sector from offset 0x8800, but best to include say 8k
> of data starting at offset 0x8000 to be sure.
>
>
>>What I think will be very useful is to translate filenames to UTF-8
>>(and maybe even UTF-7 - the latter one is not supported by OS/2 API,
>>but both are trivial to implement in 10 lines of C). This way one can
>>read all the files on Joliet image no matter what (the price being
>>that the filenames may be not immediately readable) - unless the
>>translated name is longer than 260 chars...
>
>
> I know almost nothing about this character set business. The code already
> includes unicode decoding. I know nothing about any OS/2 APIs regarding
> this stuff.
>
>
>>P.S. Would not it be easier to implement images the other way around:
>>by associating a drive letter with a file via some DMD, then let the
>>standard OS/2 mechanism recognize that the FS is ISO one?
>
>
> I've no idea. Never written a DMD before. I'm not quite sure how you'd
> associate drives with files anyway. An IFS is much easier, especially
> as it's already written.
>
>
>>If usbmsd.sys can create drives on a fly, why not do this?
>
>
> How does it do this? And why doesn't it get rid of them afterwards?
> I've never done anything with USB, but I plugged a compact flash card
> from my camera in via an adapter the other day and was amazed to find
> it worked. However, it doesn't give me a choice of drive letter and when
> I unplug it, it doesn't go away, which causes problems.
> Does anybody know what mechanisms are at work here?

Hi Paul

eCS 1.2 comes with a program called Removable Drive Monitor found in the
system's startup folder. It monitors for any insertion of USB devices.
In the past, the program had to be either downloaded and installed
manually, or it was on the hard drive and a program object had to be
added to the startup folder. Before this, one had to click on "Refresh
Removable Media" found in the drive objects folder for the USB device to
be found.

As for drive letters, you can assign the drive a premanent drive letter
using LVM. That is what I have done with all my removable media.
Otherwise, the system always chooses the drive letter.

David

[A complimentary Cc of this posting was NOT [per weedlist] sent to
Paul Ratcliffe
], who wrote in article :
> I found it at ftp://ftp.berlios.de/pub/cdrecord
> It has fixed the horrid bugs, but the code's even more of a mess now a
> couple more features have been bolted on.

Coding styles may be very different for different people... I do not
recollect thinking "what a mess" when looking at this code (but I did
not try to make it work either, just to find the actual layout of data
it reads).

> >> I will try to find the actual CD. How many sectors do you think you
> >> need? It contained about 1200 files...
> >
> > Probably just the sector from offset 0x8800, but best to include say 8k
> > of data starting at offset 0x8000 to be sure.
>
> Forget it. I've added the 'space where the null should be' check.

Good. Since my CD was CDRW which is long as rewritten...

2 more issues came to my mind:

a) it would not strip trailing ";1" from Joliet names (I recognized
that ISOFS has this problem after reading
http://arost.redirectme.net/sw/mkisofs/ yesterday).

b) It would be great if it recognized file names like v: or ac:, and
open them with OPEN_FLAGS_DASD flag, and do the necessary locking
via DosDevIOCtl, Category 8, DSK_LOCKDRIVE. (Or do the similar
thing for filenames \\.\v: or \\.\ac: - I think that contrary to
examples OPEN_ACCESS_READONLY does not work for these files).

Thanks,
Ilya

[A complimentary Cc of this posting was NOT [per weedlist] sent to
Paul Ratcliffe
], who wrote in article :
> I've never done anything with USB, but I plugged a compact flash card
> from my camera in via an adapter the other day and was amazed to find
> it worked. However, it doesn't give me a choice of drive letter and when
> I unplug it, it doesn't go away, which causes problems.

You do not just "unplug" stuff. You do

eject o:

first, so that FSD can write cached data down. I would expect that
this would remove the drive letter with LVM too (can't check, I'm
fdisked).

Hope this helps,
Ilya

P.S. Anybody ready to explain why 'eject' is not enough with UDF; why
part of functionality is moved to 'unlock' instead?

On Tue, 7 Dec 2004 21:18:14 +0000 (UTC), Ilya Zakharevich
wrote:

>> I've never done anything with USB, but I plugged a compact flash card
>> from my camera in via an adapter the other day and was amazed to find
>> it worked. However, it doesn't give me a choice of drive letter and when
>> I unplug it, it doesn't go away, which causes problems.
>
> You do not just "unplug" stuff. You do
>
> eject o:

Ah, yes. I thought I must be missing something here.

> first, so that FSD can write cached data down.

Is there any on a removable drive? I thought it operated in write-through
mode always. That's certainly what makes floppy access so bad on OS/2
compared to other systems.

The CF only seems to give me about 400kB/s on write, and it is supposedly
a 12X card, which should be 1.8MB/s in theory. I suppose I should've
measured the read speed too.... just done it and it's about 750kB/s.

> I would expect that this would remove the drive letter with LVM too

It does.