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?

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 <gerberb@zenez.com>
ZENEZ 1042 East Fort Union #135, Midvale Utah 84047

In article <Pine.LNX.4.64.0709141048270.14399@xenau.zenez.com >,
Boyd Lynn Gerber <gerberb@zenez.com> 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 <gerberb@zenez.com>
>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

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

On Sep 14, 12:48 pm, Boyd Lynn Gerber <gerb...@zenez.com> 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 <gerb...@zenez.com>
> ZENEZ 1042 East Fort Union #135, Midvale Utah 84047- Hide quoted text -
>
> - Show quoted text -

this worked

On 14 Sep, 17:05, willjay <jim.highsm...@gmail.com> 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

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 <stephen@stevedunn.ca>
>>>----------------> http://www.stevedunn.ca/ <----------------<<<
------------------------------------------------------------------
Say hi to my cat -- http://www.stevedunn.ca/photos/toby/

In article <JoJAu0.292@stevedunn.ca>,
Stephen M. Dunn <stephen@stevedunn.ca> 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 <stephen@stevedunn.ca>
>>>>----------------> http://www.stevedunn.ca/ <----------------<<<
>------------------------------------------------------------------
> Say hi to my cat -- http://www.stevedunn.ca/photos/toby/


--
Bill Vermillion - bv @ wjv . com

In article <JoKHx1.24ss@wjv.com> 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 <stephen@stevedunn.ca>
>>>----------------> http://www.stevedunn.ca/ <----------------<<<
------------------------------------------------------------------
Say hi to my cat -- http://www.stevedunn.ca/photos/toby/

----- Original Message -----
From: "Stephen M. Dunn" <stephen@stevedunn.ca>
Newsgroups: comp.unix.sco.misc
To: <distro@jpr.com>
Sent: Wednesday, September 19, 2007 6:20 PM
Subject: Re: cannot erase large file on osr6


> In article <JoKHx1.24ss@wjv.com> 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!