Path: utzoo!censor!geac!aimed!ncrcan!attcan!uunet!samsung!sdd.hp.com!zaphod.mps.ohio-state.edu!mips!pacbell.com!pacbell!att!mcdchg!ddsw1!corpane!disk!stevenw
From: stevenw@disk.UUCP (Steven Weller)
Newsgroups: comp.os.os9
Subject: Re: pd software/unix utils
Keywords: os9 unix utilities
Message-ID: <3970@disk.UUCP>
Date: 23 Aug 90 14:11:20 GMT
References: <1990Aug7.185337.4532@cs.utk.edu> <2394@mcrware.UUCP> <3300@rwthinf.UUCP> <3919@disk.UUCP> <3337@rwthinf.UUCP>
Organization: Digital Information Systems of Ky (DISK), Louisville, Ky
Lines: 67

krischan@strange.informatik.rwth-aachen.de (Christian Engel) writes:

>In article <3919@disk.UUCP> stevenw@disk.UUCP (Steven Weller) writes:
>>
>>It is not necessary to use system calls if all you want to do is 
>>copy-then-delete.  Simply write a program mv that collects all its
>>command-line parameters and forks copy with them.  If that is 
>>successful (ONLY if it is successful !) fork del to delete the 
>>file(s) with appropriate arguments.

>That's no move!!!! That's childish!

But it works, anyone can do it, it has all the facilities of copy, and
it will defragment very fragmented files.  I agree that a real mv is
a nice thing to have, 
It would be nice of Microware to supply one with OS-9.

>There are two problems:

>You don't talk about ln (link). It must modify (increment) the link count in
>the file descriptor of the file to be linked. Since there is no system call
>to do this (I've read the technical manual), you have to do the work
>on the raw device. DO YOU WANT TO SUGGEST RECORD LOCKING ON THE
>COMPLETE RAW DEVICE?!?!?! How about another process sharing time
>with ln? There is an extreme danger of a dead lock!

The descriptor can be locked out by locking the entire file.  Once that
is achieved, use a raw access to the descriptor sector (bypassing
record locking) to make the change.  Unlock the file.

Avoiding deadlocks is down to a) RBF which has the ability to spot
deadlocks between processes waiting on RBF files, and b) careful
programming.  Always claim and release resources in the same order; 
that way circular dependencies can not be formed.

>Second, there is another problem with both the mv and the ln utilities:
>if you do it by a simple program (with or without record locking)
>the process could be killed between the two modifications of the
>file system it has to do. This would result in an inconsistent file
>system.

This is the real problem.  A system state program would avoid it,
but that is not the way to go.

>In the case of system calls, they only can be interrupted
>by a reset or a power off. But there isn't any process or system call
>that is secure of these rigid methods.

System calls can be interrupted - if they sleep.  This includes all
calls to drivers.  RBF has to deal with physical media errors
encountered between operations and processes being killed at any time.
I do not know how _well_ it deals with them, however.

I will avoid ln until the rest of OS-9 knows about the link field.


Once you have a "move" command you can write a "dmove".  It forks
dsave to create a shell script which is piped through a program
that converts all the "copy" commands to "move" commands.  This
is fed into a shell which does all the work.  Another childish
solution I am afraid :o)  .

-- 
: Phone: (502) 425 9560   <<  Steven Weller  >>   Fax: (502) 426 3944 :
:   Windsor Systems, 2407 Lime Kiln Lane, Louisville, KY, 40222 USA   :
:      "A substance almost, but not quite, entirely unlike tea"       :
:        stevenw@disk.UUCP or uunet!ukma!corpane!disk!stevenw         :