Re: cannot erase large file on osr6 - SCO

This is a discussion on Re: cannot erase large file on osr6 - SCO ; Stephen M. Dunn wrote: > All of the existing command-line options that worked so well > for a long time still exist, and still work exactly the way they've > worked so well for a long time. As opposed to ...

+ Reply to Thread
Results 1 to 4 of 4

Thread: Re: cannot erase large file on osr6

  1. Re: cannot erase large file on osr6

    Stephen M. Dunn wrote:

    > All of the existing command-line options that worked so well
    > for a long time still exist, and still work exactly the way they've
    > worked so well for a long time. As opposed to the OSR6 way, in
    > which if you want a version of rm that works the way rm has worked
    > in every previous version of OpenServer, SCO Unix, or SCO Xenix
    > for the last two decades plus, you have to use the version that
    > your path, by default, *doesn't* give you.
    >
    > $And why not just move rm to rm-orig on your system and symlink
    > $the u95 version to 'rm' ?
    >
    > Why should I have to do this in order to have a version of rm
    > that, like the versions of rm on every previous version of OpenServer,
    > SCO Unix, or SCO Xenix, will delete any file I ask it to? The
    > thing should work normally right out of the box, without me having to
    > fiddle with stuff like this.


    Your points are well taken, but there is a reason behind this madness.

    The /u95/bin binaries are built out of sources that came from UnixWare;
    the /bin binaries from OpenServer (5). Although in many cases these
    came from the same original code a long time ago, they have diverged
    since then. In some cases the divergence may be unimportant, in others
    it can be large. Examples include flags which have the same letter but
    different meanings (often entirely unrelated); subtle semantic
    differences; differences in error messages (which your scripts may be
    capturing and parsing); differences in error exit codes.

    The UnixWare-sourced binaries had already been modified to support large
    files -- an undertaking which was apparently a lot more difficult than
    you might imagine. The OSR5-sourced binaries had not.

    In many cases it was not deemed _possible_ to create a merged source
    code that would provide all desired results: large file support + all
    expected OpenServer-ish behaviors (flags, semantics, message texts,
    error codes, whatever else I'm forgetting). I think there are even some
    cases where the UW (/u95) binaries have flags that directly relate to
    large file support, and which conflict in name with OSR5 flags that
    obviously mean something else.

    If the /u95/bin binaries were wholesale dumped into /bin, shell scripts
    would generally work with large files. But thousands of existing
    OSR5-specific shell scripts (things like 3rd party product install
    scripts) would have broken on the semantic shoals.

    Ideally, large file support should have been added into the OSR5-sourced
    binaries, plus any other useful flags & behaviors that could be pulled
    from the UW-sourced binaries without clashing with existing OSR5
    details. But that would have taken far more resources, so it didn't
    happen. Even if it did happen, there would probably _still_ have been a
    /u95/bin directory populated with "purer" UnixWare-derived binaries,
    because OSR6 is also supposed to be able to run UW applications with
    minimum pain. That's supposed to be done by feeding the UW apps an
    executable $PATH that emphasizes /u95/bin over /bin (while OSR5 apps
    should get the opposite).

    `rm` does seem like a particularly egregious example, after all, how
    much complexity can there be in doing ... unlink(argv[1])? The OSR506
    and UW713 `rm` man pages document the same flags (with probably the same
    semantics). Perhaps `rm` got shuffled into the wrong bin. Hmmm, the
    UW713 man page does mention one feature not present in OSR5: "As an aid
    to BSD migration," `rm - foo` acts the same as `rm -- foo`. So there's
    something your UW shell scripts could start tripping on right away if
    they didn't have /u95/bin first in their path.

    I will bet there are half a dozen other issues of similar subtlety
    between the OSR5 and UW7 `rm` commands alone. When you get to complex
    commands like `cpio` or `dd`, the differences are probably overwhelming.
    Even given their common ancestry and the likely fact that these two
    branches of the Unix family tree are closer together than most other
    branches.

    It still sucks that `/bin/rm my-6gb-file` fails. SCO should have been
    running a rearguard action after OSR6 first shipped, quickly modifying
    as many as possible of the OSR5-based /bin commands to support large
    files. As we all know, that energy was spent on a different rearguard
    action...

    >Bela<


  2. Re: cannot erase large file on osr6

    In article <200709191715.aa25401@deepthought.armory.com> Bela Lubkin writes:
    [...lots of good information...]

    Thanks for the insight into what goes on behind the scenes.

    I most fundamentally agree with the following:

    $It still sucks that `/bin/rm my-6gb-file` fails. SCO should have been
    $running a rearguard action after OSR6 first shipped, quickly modifying
    $as many as possible of the OSR5-based /bin commands to support large
    $files. As we all know, that energy was spent on a different rearguard
    $action...

    I still think the horse should have been put *before* the
    cart: make the thing work properly *before* shipping. Yes, it's a lot
    of effort (and yes, we all know it's common practice in the software
    industry to ship products before they're finished), but I don't
    believe anyone ever said that writing a new (or even not-quite-new but
    substantially-updated) version of Unix was supposed to be a quick and
    easy project.

    The bottom line, for me, is that if OSR6 is supposed to support
    large files, it should support large files. Not just in the kernel,
    not just in a bunch of utilities that either aren't in the default PATH
    or are in the default PATH but listed farther down the PATH than a
    bunch of utilities with the same names that *don't* support large
    files. If you say you support large files, then *all* the utilities
    should support large files unless there's a darn good reason not to.
    And "It's a lot of work so we can't be bothered" isn't a darn good
    reason. It's a cop-out. If maintaining compatibility with two
    somewhat-incompatible predecessors (OSR5 and UnixWare) leads to a lot
    of work, well, it leads to a lot of work. If there's anyone
    within SCO who was involved in planning or directing the OSR6 project
    who *didn't* think it would be a lot of work, maybe they should
    have been working behind the counter at McDonald's instead.

    Let me give you another example. At least on OSR5, /bin/compress,
    /bin/uncompress, and /bin/zcat are the same program. Each one
    does a different thing, and each one has at least a slightly
    different set of command-line options. Yet they all work. If
    someone was clever enough to figure out how to do that, surely
    they're clever enough to figure out how to handle the one and only
    semantic difference that anyone's been able to find yet between
    OSR5 rm and UnixWare rm (and, let's be honest here: if you try
    to use that one and only feature, the ability to type rm - foo,
    on OSR5, you get an error message; you're *not* going to have that
    coded into an existing, tested, known-to-work-properly OSR5/Unix/Xenix
    shell script) and make both commands handle large files. Yes, I
    agree with Bela that rm is a "particularly egregious example" of
    a command with reasonably simple semantics and reasonably simple
    actions, and (for example) dd or tar could be considerably harder
    to modify.

    There are other commands which, like rm, have pretty simple
    command-line syntax and pretty simply actions. chgrp is another
    example; OSR5 offers one option, UnixWare offers two (one of which
    is identical to the OSR5 option, and the other one of which causes
    OSR5 chgrp to abort with an error message), and their syntax appears
    to be identical otherwise. And since the one extra option in UnixWare
    causes the OSR5 version to abort with an error message, it's not
    something that would be depended upon by any OSR5 shell script.
    The porting effort to make two 100% compatible versions of it
    (one 100% compatible with OSR5, the other with UnixWare) should not
    be huge. cat is an even better example; as far as I can tell from the
    man pages, both UnixWare and OSR5 use the very same five options, with
    the very same meanings, the very same command-line syntax, and the
    very same exit codes. That's another command that shouldn't take a
    heck of a lot of effort to port.

    OK, if there wasn't enough time or manpower to fix 'em all before
    the ship-by date that was set by some manager, at least pick the
    low-hanging fruit. And then do as Bela suggests: run a rearguard
    action to fix the others as expeditiously as possible.

    Microsoft sure ain't perfect, but they don't make me use two
    different versions of Explorer on XP, one which works fine on FAT and
    FAT32 filesystems but doesn't work properly on NTFS and another one
    (which is not the default one) which works with any of these
    filesystems.
    --
    Stephen M. Dunn
    >>>----------------> http://www.stevedunn.ca/ <----------------<<<

    ------------------------------------------------------------------
    Say hi to my cat -- http://www.stevedunn.ca/photos/toby/

  3. Re: cannot erase large file on osr6

    > files. If you say you support large files, then *all* the utilities
    > should support large files unless there's a darn good reason not to.
    > And "It's a lot of work so we can't be bothered" isn't a darn good
    > reason.


    With this I do have to agree.
    The end result would have been no OSR6 in any reasonable time frame. It
    already took way too long such that gobs of people moved to linux to get
    things like kernel threads and large files and 64bit and a filesystem that
    isn't 1/5th the speed of everything else, even windows.

    Probably what they should really have done was keep improving the migration
    support from osr5 to unixware, keep improving the osr5 binary support in
    unixware, keep selling osr5 more or less as-is with absolutely minimal
    investment in enhancing or updating it, and keep improving unixware as the
    flagship, and price unixware so that everyone can have it.

    That way people that don't want to suffer any changes can just keep buying
    osr5, and everyone else gets fully sane/consistent/working unixware.

    -bkw


  4. Re: cannot erase large file on osr6

    In article ,
    Stephen M. Dunn wrote:
    >In article <200709191715.aa25401@deepthought.armory.com> Bela Lubkin writes:
    >[...lots of good information...]
    >
    > Thanks for the insight into what goes on behind the scenes.
    >
    > I most fundamentally agree with the following:
    >
    >$It still sucks that `/bin/rm my-6gb-file` fails. SCO should have been
    >$running a rearguard action after OSR6 first shipped, quickly modifying
    >$as many as possible of the OSR5-based /bin commands to support large
    >$files. As we all know, that energy was spent on a different rearguard
    >$action...


    > I still think the horse should have been put *before* the
    >cart: make the thing work properly *before* shipping. Yes, it's a lot
    >of effort (and yes, we all know it's common practice in the software
    >industry to ship products before they're finished), but I don't
    >believe anyone ever said that writing a new (or even not-quite-new but
    >substantially-updated) version of Unix was supposed to be a quick and
    >easy project.


    > The bottom line, for me, is that if OSR6 is supposed to support
    >large files, it should support large files. Not just in the kernel,
    >not just in a bunch of utilities that either aren't in the default PATH
    >or are in the default PATH but listed farther down the PATH than a
    >bunch of utilities with the same names that *don't* support large
    >files. If you say you support large files, then *all* the utilities
    >should support large files unless there's a darn good reason not to.
    >And "It's a lot of work so we can't be bothered" isn't a darn good
    >reason. It's a cop-out. If maintaining compatibility with two
    >somewhat-incompatible predecessors (OSR5 and UnixWare) leads to a lot
    >of work, well, it leads to a lot of work. If there's anyone
    >within SCO who was involved in planning or directing the OSR6 project
    >who *didn't* think it would be a lot of work, maybe they should
    >have been working behind the counter at McDonald's instead.


    How is this for an idea of the top of my head as a work-around.

    Rename the original rm.

    Write a wrapper called 'rm'.

    Check the file size. If it's 2GB or under, call the original
    rm, if it's larger call the one in the u95 directory.

    Bill
    --
    Bill Vermillion - bv @ wjv . com

+ Reply to Thread