cannot erase large file on osr6 - SCO

This is a discussion on cannot erase large file on osr6 - SCO ; i created a file dump using smbtar and rcmd to my osr6 and now i have a file that is not manageable, cannot erase mv delete what ever. -rw-r--r-- 1 root sys 29968886640 Sep 10 10:51 cdrive.out # rm ./ ...

+ Reply to Thread
Results 1 to 10 of 10

Thread: cannot erase large file on osr6

  1. cannot erase large file on osr6

    i created a file dump using smbtar and rcmd to my osr6 and now i have
    a file that is not manageable, cannot erase mv delete what ever.

    -rw-r--r-- 1 root sys 29968886640 Sep 10 10:51
    cdrive.out

    # rm ./
    cdrive.out
    rm: ./cdrive.out non-existent: Value too large for defined data type
    (erro
    r
    79)
    #

    anybody know what to do?


  2. Re: cannot erase large file on osr6

    On Fri, 14 Sep 2007, willjay wrote:
    > i created a file dump using smbtar and rcmd to my osr6 and now i have
    > a file that is not manageable, cannot erase mv delete what ever.
    >
    > -rw-r--r-- 1 root sys 29968886640 Sep 10 10:51
    > cdrive.out
    >
    > # rm ./
    > cdrive.out
    > rm: ./cdrive.out non-existent: Value too large for defined data type
    > (erro
    > r
    > 79)
    > #
    >
    > anybody know what to do?


    How about /u95/bin/rm ?

    --
    Boyd Gerber
    ZENEZ 1042 East Fort Union #135, Midvale Utah 84047

  3. Re: cannot erase large file on osr6

    In article ,
    Boyd Lynn Gerber wrote:
    >On Fri, 14 Sep 2007, willjay wrote:
    >> i created a file dump using smbtar and rcmd to my osr6 and now i have
    >> a file that is not manageable, cannot erase mv delete what ever.
    >>
    >> -rw-r--r-- 1 root sys 29968886640 Sep 10 10:51
    >> cdrive.out
    >>
    >> # rm ./
    >> cdrive.out
    >> rm: ./cdrive.out non-existent: Value too large for defined data type
    >> (erro
    >> r
    >> 79)
    >> #
    >>
    >> anybody know what to do?

    >
    >How about /u95/bin/rm ?
    >
    >--
    >Boyd Gerber
    >ZENEZ 1042 East Fort Union #135, Midvale Utah 84047



    Or how about finding the inode and then unlink the inode and then
    run fsck to clean up the mess.

    Bill
    --
    Bill Vermillion - bv @ wjv . com

  4. Re: cannot erase large file on osr6

    willjay typed (on Fri, Sep 14, 2007 at 09:05:34AM -0700):
    | i created a file dump using smbtar and rcmd to my osr6 and now i have
    | a file that is not manageable, cannot erase mv delete what ever.
    |
    | -rw-r--r-- 1 root sys 29968886640 Sep 10 10:51
    | cdrive.out
    |
    | # rm ./
    | cdrive.out
    | rm: ./cdrive.out non-existent: Value too large for defined data type
    | (erro
    | r
    | 79)
    | #
    |
    | anybody know what to do?

    A long shot:
    Can you 'split' the file?

    - Jeff Hyman

  5. Re: cannot erase large file on osr6

    On Sep 14, 12:48 pm, Boyd Lynn Gerber wrote:
    > On Fri, 14 Sep 2007, willjay wrote:
    > > i created a file dump using smbtar and rcmd to my osr6 and now i have
    > > a file that is not manageable, cannot erase mv delete what ever.

    >
    > > -rw-r--r-- 1 root sys 29968886640 Sep 10 10:51
    > > cdrive.out

    >
    > > # rm ./
    > > cdrive.out
    > > rm: ./cdrive.out non-existent: Value too large for defined data type
    > > (erro
    > > r
    > > 79)
    > > #

    >
    > > anybody know what to do?

    >
    > How about /u95/bin/rm ?
    >
    > --
    > Boyd Gerber
    > ZENEZ 1042 East Fort Union #135, Midvale Utah 84047- Hide quoted text -
    >
    > - Show quoted text -


    this worked


  6. Re: cannot erase large file on osr6

    On 14 Sep, 17:05, willjay wrote:
    > i created a file dump using smbtar and rcmd to my osr6 and now i have
    > a file that is not manageable, cannot erase mv delete what ever.
    >
    > -rw-r--r-- 1 root sys 29968886640 Sep 10 10:51
    > cdrive.out
    >
    > # rm ./
    > cdrive.out
    > rm: ./cdrive.out non-existent: Value too large for defined data type
    > (erro
    > r
    > 79)
    > #
    >
    > anybody know what to do?


    You need to use the large file aware version of rm to remove large
    files.
    For more on large file aware commands see:

    http://osr600doc.sco.com/en/FS_admin/largefiles.html

    John


  7. Re: cannot erase large file on osr6

    In article <1190039854.739803.248040@n39g2000hsh.googlegroups. com> jboland@sco.com writes:
    $You need to use the large file aware version of rm to remove large
    $files.

    I see the rationale given on the large file man page, but it seems
    rather silly to me. If SCO's interested in user feedback, call
    this one an enhancement request.

    I can understand why one might make the administrator jump through
    some extra hoops in order to create a filesystem that supports
    large files. But once that's been done, it really ought to be
    transparent to the user, for the most part. If rm removes a file
    on a non-large-file filesystem, it should remove a file on a large-file
    filesystem. If mv moves a file on a non-large-file filesystem, it
    should move a file on a large-file filesystem. And so on. Only
    commands which are somehow more dangerous if used on large files, or
    which might have different side effects when used on large files,
    should be treated differently - and, arguably, the same command should
    work on both types of files, albeit perhaps requiring a "yes, I know,
    I want you to do this to a large file" command-line option to work on
    a large file and spitting out a *meaningful* error message (such as
    "foo is a large file; -l option must be specified to work with large
    files", as opposed to "foo non-existent [which is clearly false]: Value
    too large for defined datatype (error 79)") if a user attempts to use
    it on a large file without specifying the large-file option.

    For that matter, why should we differentiate between removing a
    large file and removing a non-large file? We make no distinction
    between removing a file, a device node, or a symbolic link; rm
    handles them all equally well. Why, then, do we make a distinction
    between removing a small file and removing a large file? There
    shouldn't be one.

    (Yes, there may be differences behind the scenes in what system
    call(s) rm needs to use depending on whether it's working on a
    small file or a large file. But that's not the user's problem, just
    as it isn't the user's problem whether mv can do its job simply
    by issuing a rename() system call or if it has to copy the file
    to another filesystem and then remove the old file. We know that
    it's possible to write a version of rm which can handle both large
    and small files perfectly well; the u95 version does.)
    --
    Stephen M. Dunn
    >>>----------------> http://www.stevedunn.ca/ <----------------<<<

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

  8. Re: cannot erase large file on osr6

    In article ,
    Stephen M. Dunn wrote:
    >In article <1190039854.739803.248040@n39g2000hsh.googlegroups. com> jboland@sco.com writes:
    >$You need to use the large file aware version of rm to remove large
    >$files.


    [Lucretia Deletia chops away a lot of text - wjv]


    > I see the rationale given on the large file man page, but it seems
    >rather silly to me. If SCO's interested in user feedback, call
    >this one an enhancement request.


    > I can understand why one might make the administrator jump
    >through some extra hoops in order to create a filesystem that
    >supports large files. But once that's been done, it really
    >ought to be transparent to the user, for the most part. If
    >rm removes a file on a non-large-file filesystem, it should
    >remove a file on a large-file filesystem. If mv moves a file
    >on a non-large-file filesystem, it should move a file on a
    >large-file filesystem. And so on. Only commands which are somehow
    >more dangerous if used on large files, or which might have
    >different side effects when used on large files, should be
    >treated differently - and, arguably, the same command should
    >work on both types of files, albeit perhaps requiring a "yes,
    >I know, I want you to do this to a large file" command-line
    >option to work on a large file and spitting out a *meaningful*
    >error message (such as "foo is a large file; -l option must
    >be specified to work with large files", as opposed to "foo
    >non-existent [which is clearly false]: Value too large for
    >defined datatype (error 79)") if a user attempts to use it on a
    >large file without specifying the large-file option.


    You said in the above paragraph:

    > - and, arguably, the same command should
    >option to work on a large file and spitting out a *meaningful*
    >error message (such as "foo is a large file; -l option must
    >be specified to work with large files", ...


    This suggestion is similar to what happens when Linux distros
    change their options and breaks shell scripts which use
    commands that have worked for a long time - and all of a sudden
    break with nag messages, warning messages, and other discouraging
    items.

    No all things work from the command line and you don't want to
    change operations of something that worked so well for a long
    time that may break existing scripts admins may have written.

    That's enough to make them distrust future versions of the OS.

    > For that matter, why should we differentiate between removing a
    >large file and removing a non-large file? We make no distinction
    >between removing a file, a device node, or a symbolic link; rm
    >handles them all equally well. Why, then, do we make a distinction
    >between removing a small file and removing a large file? There
    >shouldn't be one.


    .....

    > (Yes, there may be differences behind the scenes in what system
    >call(s) rm needs to use depending on whether it's working on a
    >small file or a large file. But that's not the user's problem, just
    >as it isn't the user's problem whether mv can do its job simply
    >by issuing a rename() system call or if it has to copy the file
    >to another filesystem and then remove the old file. We know that
    >it's possible to write a version of rm which can handle both large
    >and small files perfectly well; the u95 version does.)


    And why not just move rm to rm-orig on your system and symlink
    the u95 version to 'rm' ?

    Bill
    >--
    >Stephen M. Dunn
    >>>>----------------> http://www.stevedunn.ca/ <----------------<<<

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



    --
    Bill Vermillion - bv @ wjv . com

  9. Re: cannot erase large file on osr6

    In article bv@wjv.com writes:
    $This suggestion is similar to what happens when Linux distros
    $change their options and breaks shell scripts which use
    $commands that have worked for a long time - and all of a sudden
    $break with nag messages, warning messages, and other discouraging
    $items.

    Previous shell scripts have used a version of rm that worked for a
    long time - if you asked it to delete a file, it deleted it. The file
    could be any size, from zero to whatever the largest file supported by
    the OS was, and rm would simply delete it. Now, that no longer works.
    Previous shell scripts which could rely on "rm foo" being able to
    delete foo (subject to permissions, of course) regardless of how large
    or small foo was are already broken by the change in functionality.

    Anyway, then, let's reverse it. If you want a version of rm
    that works properly (i.e. it deletes any file you ask it to), use
    rm. If you want a version that will work properly on small files
    and refuse to delete large files (i.e. works differently than the
    way rm has worked for the last couple of decades) then add a
    command-line option that makes it work like this. That will
    satisfy your requirement below:

    $No all things work from the command line and you don't want to
    $change operations of something that worked so well for a long
    $time that may break existing scripts admins may have written.

    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.

    Plus, your suggestion will quite possibly result in rm suddenly
    breaking if I install a patch or update; if that patch or update
    puts a new verson of the "I only like small files" rm back in the
    usual place, I have to fix it again. And again and again, if future
    updates include this. I'm not sure if OSR6 has the same verification
    code (running every week and/or every time I install an update)
    that OSR5 had, but your suggestion will also result in warnings
    from that code.

    No, the thing should just work properly from the start. It
    should delete any file to which you have sufficient access.
    --
    Stephen M. Dunn
    >>>----------------> http://www.stevedunn.ca/ <----------------<<<

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

  10. Re: cannot erase large file on osr6


    ----- Original Message -----
    From: "Stephen M. Dunn"
    Newsgroups: comp.unix.sco.misc
    To:
    Sent: Wednesday, September 19, 2007 6:20 PM
    Subject: Re: cannot erase large file on osr6


    > In article bv@wjv.com writes:
    > $This suggestion is similar to what happens when Linux distros
    > $change their options and breaks shell scripts which use
    > $commands that have worked for a long time - and all of a sudden
    > $break with nag messages, warning messages, and other discouraging
    > $items.
    >
    > Previous shell scripts have used a version of rm that worked for a
    > long time - if you asked it to delete a file, it deleted it. The file
    > could be any size, from zero to whatever the largest file supported by
    > the OS was, and rm would simply delete it. Now, that no longer works.
    > Previous shell scripts which could rely on "rm foo" being able to
    > delete foo (subject to permissions, of course) regardless of how large
    > or small foo was are already broken by the change in functionality.
    >
    > Anyway, then, let's reverse it. If you want a version of rm
    > that works properly (i.e. it deletes any file you ask it to), use
    > rm. If you want a version that will work properly on small files
    > and refuse to delete large files (i.e. works differently than the
    > way rm has worked for the last couple of decades) then add a
    > command-line option that makes it work like this. That will
    > satisfy your requirement below:
    >
    > $No all things work from the command line and you don't want to
    > $change operations of something that worked so well for a long
    > $time that may break existing scripts admins may have written.
    >
    > 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.
    >
    > Plus, your suggestion will quite possibly result in rm suddenly
    > breaking if I install a patch or update; if that patch or update
    > puts a new verson of the "I only like small files" rm back in the
    > usual place, I have to fix it again. And again and again, if future
    > updates include this. I'm not sure if OSR6 has the same verification
    > code (running every week and/or every time I install an update)
    > that OSR5 had, but your suggestion will also result in warnings
    > from that code.
    >
    > No, the thing should just work properly from the start. It
    > should delete any file to which you have sufficient access.


    There is obviously an argument for defulting the system to use utils that
    work fully.

    But this is SCO, not Linux or Windows or Sony PlayStation. The overwhelming
    majority of SCO users are more concerned with backwards compatibility, down
    to the tiniest detail, above _all_ else. And because of the way and the
    contexts in which they use the OS, they are not wrong.

    If you are a VAR with an app that currently works on on OSR5, then that app
    does not involve any such thing as a file over 2G in size. It does not
    matter if "rm" or anything else can handle +2G file. It _does_ matter that
    all the zillion features of the system, such as "rm" behave exactly the same
    as the previous version. This means such things as command line options must
    all be the same, they must all behave exactly the same, fail or work under
    exactly the same conditions, error & other messages must all be the same and
    occur or not, under the same conditions.

    If the large-file aware "rm" is a new binary generated from new source
    unrelated from the old one, (which it is), then in the specific case of
    SCO, it probably does make more sense to default the system to using the old
    binary instead of the new one, even though that constitutes a system that is
    basically broken from most perspectives.

    Not all OS's are used by the same people with the same needs and the same
    expectations and the same tolerance for the same types of problems or
    unexpected behaviour. You would rather have an rm that handles all files by
    default, and apparently don't care if it bahaves differently from the
    preceding 15 years. Fine, that's you. you are not the world. What is obvious
    to you is just as obviously backwards to someone else, and they are not
    wrong or illogical just because they are not a clone of you. Your idea of
    "expected behaviour" simply differs from that of most SCO users. You are not
    wrong, neither are they. But since SCO's customers are SCO users, then the
    most correct and logical thing for SCO to do is to meet SCO users
    expectations, not yours or more generally Linux users expectations.

    Most existing OSR5 users could care less about a 2G file, but if rm, buried
    in some script or buried in a system() command in some app, suddenly
    developed some subtle change in behaviour like, producing a output that
    doesn't exactly match what his script/app knows how to parse, or worse, has
    command line options that don't do the same things as before, that could
    cost him a _lot_ of time and grief and maybe even one or more customers,
    both for direct and indirect reasons.

    The fact that rm is a basic sort of util that mostly does the same thing on
    every OS, and that most people only use the most basic command line options
    that almost every OS has and that do the same things on every OS, and that
    most people probably don't parse the output of rm, nor be affected much if
    it started generating output in some situation where it used to be silent,
    or vice/versa, none of that is a legitimate reason for replacing rm with a
    new and improved one. All those probablys and mosts don't add up to
    anything.

    Also, remember that this isn't about "rm" this is about a zillion things
    throughout the system. It's all true for rm only because it's true for
    everything, rm is simply no exception.

    Users that want to make more full use of OSR6's new features, and are OK
    with dealing with some breakage along the way, are free to switch their
    system to default to use all the new utils instead of the old ones by just
    placing the u95 bins in their PATH ahead of the other bin directories. or
    copy the binaries right into the normal paths to handle commands that
    specify the full path.

    --
    Brian K. White brian@aljex.com http://www.myspace.com/KEYofR
    +++++[>+++[>+++++>+++++++<<-]<-]>>+.>.+++++.+++++++.-.[>+<---]>++.
    filePro BBx Linux SCO FreeBSD #callahans Satriani Filk!


+ Reply to Thread