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