ISOFS - OS2

This is a discussion on ISOFS - OS2 ; 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 ...

+ Reply to Thread
Page 1 of 3 1 2 3 LastLast
Results 1 to 20 of 42

Thread: ISOFS

  1. ISOFS

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

    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.

    Thanks,
    Paul

  2. Re: ISOFS

    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.

  3. Re: ISOFS

    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!

  4. Re: ISOFS

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

  5. Re: ISOFS

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


  6. Re: ISOFS

    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.

  7. Re: ISOFS

    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.

  8. Re: ISOFS

    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

  9. Re: ISOFS

    [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

  10. Re: ISOFS

    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.

  11. Re: ISOFS

    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.

  12. Re: ISOFS

    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


  13. Re: ISOFS

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

  14. Re: ISOFS

    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.

  15. Re: ISOFS

    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.

  16. Re: ISOFS

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




  17. Re: ISOFS

    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

  18. Re: ISOFS

    [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

  19. Re: ISOFS

    [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?

  20. Re: ISOFS

    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.

+ Reply to Thread
Page 1 of 3 1 2 3 LastLast