amiga-request@ab20.larc.nasa.gov (Amiga Sources/Binaries Moderator) (05/08/91)
Submitted-by: grahamw@cpsc.ucalgary.ca (William Graham)
Posting-number: Volume 91, Issue 102
Archive-name: devices/virt-alpha/part03
#!/bin/sh
# This is a shell archive. Remove anything before this line, then unpack
# it by saving it into a file and typing "sh file". To overwrite existing
# files, type "sh file -c". You can also feed this as standard input via
# unshar, or by typing "sh <file", e.g.. If this archive is complete, you
# will see the following message at the end:
# "End of archive 3 (of 4)."
# Contents: virt_mine.doc
# Wrapped by tadguy@ab20 on Tue May 7 20:50:17 1991
PATH=/bin:/usr/bin:/usr/ucb ; export PATH
if test -f 'virt_mine.doc' -a "${1}" != "-c" ; then
echo shar: Will not clobber existing file \"'virt_mine.doc'\"
else
echo shar: Extracting \"'virt_mine.doc'\" \(32366 characters\)
sed "s/^X//" >'virt_mine.doc' <<'END_OF_FILE'
X
X
X;----------------------------------------------------------------------------
XJan 7 91
X
X - we need a skeleton device driver; preferably a RAM drive in ML source
X
Xto consume a file:
X
X get:
X name
X size
X *sparrwed flags
X *comments
X *datestamp
X actual position on media
X create:
X master checksum
X incremental checksum
X kind of file (figure this out)
X should be able to take apart qbak disks (even if not ordered)
X
Xfiles should be consumed relative to their sub-directories.
X
Xonce a file is consumed it appears at the current level of the workspace
Xif an entire media is consumed then that media appears in the workspace
X
Xfrom workbench you can move the file, from cli you can rename it
X
Xif a file has duplicates then the user should somehow be informed about
Xthe duplicates, and where they are.
X
X;----------------------------------------------------------------------------
XJan 7 91
X
Xso for a minimum implementation:
X
X read a disk, all contents into a fascimile image in the mega database
X
X present the mega database via a device driver, visible to wb and cli.
X
X search the mega database for duplicate instances, and make locations
X visible to user immediately.
X
X;----------------------------------------------------------------------------
X
Xanother way:
X
X read in a disk, stash contents into mega (assign disk id number)
X print a list of all duplicates
X support building of a master image
X from a master image can do diff for near duplicates
X
X;------------------------------------------------------------------------
X
Xread dir (or media)
X tell-database-i-am-in-dir-x
X if any sub-dirs then call self recursively with subdir
Xloop: read next file, add to database,goto loop till done
X tell-database-i-am-out-of-dir-x
X exit
X
Xi-am-in-dir-x
X add x name to database, remember position
X
Xi-am-out-of-dir
X set jump of array size in old position as end-of-dir
X
Xadd-to-database
X array:
X is file or dir, if dir then marks off certain # of array els
X
X;----------------------------------------------------------------------
X
X - need to be able to flexibly add and remove files from conceptual level
Xof dir. current file systems, such as those on harddrives probably have
Xa hash table off to a subdir, which then has its own hash table off to its
Xportions.
X
X - we can emulate this by having each dir in an array, linked together by
Xa flexible scheme
X
X - entire database should be checksummable by segment to prevent trashing
Xfrom some outside source
X
X - we could actually "have" dirs on disk, and their contents would be only
X single files describing that disks normal contents
X
X - then at the top level we'd have media names rather than ordinary dirs?
X
X - a "media" should also be a dir i guess, in that all the subdirs and files
X in it are given the same media id number. where the name of the "media"
X as a dir is the same as the agreed upon id number, and all subdirs and
X stuff just keep their original names.
X
X - the database should be all in ram at a time however i think? hmmm
X but it can probably be around 1/2 meg, and more error prone that way...
X
X;-----------------------------------------------------------------------
X
Xok so the scheme is:
X
X - we assign a media number for the disk we are consuming, that
X becomes its dir, "consume" then call "create-dir"
X
Xcreate-dir:
X *doesn't* ask for original media (of course) creates dir in image
Xmove:
Xrename:
X *doesn't* ask for original media, rather just updates internal image.
X can move into garbage, may be special command to forget a duplicate.
X
Xread:
Xwrite:
Xedit:
Xdelete:
X operates on specified media (may ask user to insert disk #x)
X
X
X - theory is that you should be able to do actual work from the virtual
X enviroment, all normal i/o access to the file works as normal, its just
X its conceived position that is indirect/deferred.
X
X
Xopen old file
Xopen new file
Xread
Xwrite
Xclose
Xseek
Xwaitchar
Xexamine object
Xexamine next
Xdiskinfo
Xparent
Xdelete object
Xcreate dir
Xlocate object
Xcopy dir
Xfree lock
Xset protect
Xsetcomment
Xrename object
Xinhibit
Xrename disk
X
X;------------------------------------------------------------------------
Xjanuary 16th:
X
X - accept and handle all dos device packets:
X DIE
X OPENRW
X OPENOLD
X OPENOLD
X READ
X WRITE
X CLOSE
X SEEK
X - do normal stuff, like checking if file is in this dir
X - pass request onto the real device (with full file path)
X EXAMINE NEXT
X EXAMINE OBJECT
X FREE LOCK
X LOCATE OBJECT
X INFO
X PARENT
X DELETE OBJECT
X CREATE DIR
X COPY DIR
X SET PROTECT
X SET COMMENT
X RENAME OBJECT
X - talk to my own information (pass request to my info handler)
X DISK INFO
X - talk to my own info dir
X inhibit
X rename
X morecache
X waitchar
X flush
X rawmode
X - dont support
X
X;------------------------------------------------------------------------
X
X
X There is an indirect level of requests, some requests get passed
Xonto the appropriate media, other requests get intercepted and passed to
Xmy own handler.
X
X In a sense there are three main segments
X
X 1) the VIR: device which gets all initial requests.
X
X 2) the normal device which is an i/o request destination.
X
X 3) another not-visible "device" of mine which provides
X the functionality of VIR:
X
X Part (3) must have the following modular upgradable components
X
X receive and return the desired info from standard
X requests, as based on an internal database
X
X the internal database being structured in such a way
X as that it is accessible and extensible
X
X possibly being located on disk for sturdyness
X
X;----------------------------------------------------------------------------
X
X possible structures for vir: internal database
X
X CHEAP - doubly linked list of names, with branches at dirs
X supplemented by info structure per file
X IF RAM - written to disk occasionaly as backup
X - always loads up as a clean minimal memory whenever possible
X IF DISK - mockup directory structure
X
X GOOD - Linked list of mini-hashed tables using the perfect hash
X - each hashed reference
X IF RAM - each hashed reference points to a chunk of data with all
X file quals
X IF DISK - each hash table has an associated file, acts same as above
X
X General
X - there are browse commands and create/delete commands mostly
X
X - all commands get passed to whatever handler, they get
X back the information they want...
X
X dirs
X - each name points to a place, if its a dir then that
X place is either a sub hash or a new linked list...
X
Xrequired info:
X link.l forward
X name 130 chars
X size.l
X protect.b
X edit date.l
X master csum.l
X csums.l (little csums)
X comments (if any)
X
X
X
X get:
X name
X size
X sparrwed flags
X comments
X datestamp
X actual position on media
X create:
X master checksum
X incremental checksum
X kind of file (figure this out)
X should be able to take apart qbak disks (even if not ordered)
X
X
X - can we use the management implementation scheme already in place
X in a standard ram drive?
X
X
X
X - all packet commands act as normal except these ones:
X
X OPENNEW
X - is not permitted, return some fail condition
X OPENRW
X -
X OPENOLD
X READ
X WRITE
X CLOSE
X SEEK
X - passes request "verbatim" onto real owner
X flags the client as reply path
X;---------------------------------------------------------------------------
X
Xdear matt
X here is a case where you're actually releasing something to the
X public domain is going to come back and help you in turn. I
X wish that I were so lucky! (if I could keep my stuff from being
X censored!).
X
X - lattice requires a -V on this
X - Note that we can use "handler" which is supposedly better.
X
X - Minimally modify the device driver
X - Submit modified device to Matt Dillion for checking if bug free
X
X - Allow all file management to still function
X - Remove OpenNew
X - Add "real owner" field to ram file node
X - Read/Write requests get passed to real owner device
X - force all files to have a very small size (preferably 0)
X
X - add these functions
X - reload vir: (from disk database)
X - unload vir: (to disk database)
X - coalesce: (search and merge duplicate files)
X - toolbox space
X
X;----------------------------------------------------------------------------
X
X - write a "learn" function
X acquire media references onto virtual device
X (have media reference)
X imbed an "info" function into this learn
X vir: to vir: should acquire others special junk
X talks to a special vir: packet
X
X - pass requests onto device (named reference?)
X - either must have internal "positive id"
X -
X
X;--------------------------------------------------------------------------
X
X - LEARN is just a COPY which writes a special packet type to host
X - build up info about next file, export to vir:
X - do directories etc.
X
X - open new, as called by learner writes a special header to file,
X and thats all
X
X - open old automatically checks if header is mine, if mine then
X patches request onto real destination.
X
X - each of my format files has its full path name imbedded in itself
X
X - how do we refer to the specific device? get source for a copy
X command (such as arp copy etc).
X
Xtypically
X
X - a user issues a dos specific command
X - whatever utility passes the path along to DOS
X - dos parses out the device
X - dos attempts to access that device, if not present it requests it
X - the file is accessed
X
Xchanges
X - i need to supply the positive id of a media type, not merely
X the name but the internal def'n unique identifier data
X
X - this may not be possible to issue at a high level?
X why? how do people discriminate normally? simply by device?
X so i could just say insert disk in df0?
X
X - i guess i really have to ask for not merely a named device
X but a specific handle for a device...
X
X;---------------------------------------------------------------------------
XJanuary 18th 1991
X
XSIMPLE IMPLEMENTATION SET:
X
X FEATURES:
X - ACQUISITION -> learning media (quals/csums)
X - PASS THRU -> requesting external online/offline media
X - COALESCING -> locating duplicates (csums)
X
X INTERNAL PHYSICAL COMPONENTS:
X - wild card handling + recursive dir descent
X - file and directory management
X - amigados packet handing
X - handler skeleton
X
X VISIBLE PHYSICAL COMPONENTS:
X - learner
X - coalescer
X - device driver
X - (device driver internal data block)
X
X INTERNAL LOGICAL COMPONENTS:
X - all I/O commands are pass thru (to real device)
X - all management commands are managed by moi
X - the stub which passes off to either of above
X
X ATTACK:
X - clean up Matts code into C++ "strands" of functionality
X (seperate all internal physical components)
X - First write AQUISITION
X such that RAM DRIVE can aquire indirect references
X - Write PASS THRU
X (possibly at same time) such that RAM DEVICE is now
X functioning virtually.
X - Rewrite database such that it is disk resident always
X - Write COALESCE
X - Write ARCHIVAL UTILITY
X - Write TOOLSPACE with CLOCK, POWEROFF, TRASHCAN, SCRIPT-EXE
X
X
X;---------------------------------------------------------------------------
X
XPositive identification of offline media:
X
X - We can't use a straight numbering scheme, unless we retain the
X disk positive ID as well (which is feasible)
X
X - Does each file retain its entire path? Yes, except perhaps its
X master media. The reason being that the file can be moved around
X the vir: space, but still retains its linkage to its physical
X existance. The media positive id could be maintained as a
X seperate node, always referenced however, by the file.
X
X - Unless some obvious, simple and efficient scheme can be arranged
X for storing media positive ids seperately I may as well store
X it specifically for each file. This wastes tons of ram, so I'll
X have to think about it.
X
X - Agreed upon ID numbers should grow by multiples of 100 just to
X leave insertion room if required.
X
X - AmigaDos implements a mechanism to request a positively ID'ed
X media. How do I patch into that mechanism? [ I dunno, emulate it! ]
X
X - What constitutes a positive ID under AmigaDOS (what do I stash).
X
X - I can emulate the AmigaDOS positive ID scheme if I stash away
X the media datestamp,checksum,name, then perform my own search
X for that media. If I fail to find the media I am looking for
X I guess I should fail, although there should be an option to
X force acceptance of generic media's.
X
X - When my device driver attempts to pass the DOS packet off to the
X proper device its going to have to search the device list for
X the positive ID qualities, and then use the general quals (name)
X to open up that device for packet communications, then pass off
X the packet to it (i presume).
X
XWhich brings us to another question:
X
X - I presume I can open a DOS device quite normally and pass off
X a packet to that device. But it would be truly grand if I could
X drop myself out of the process...simply connect my client to
X their real request and not require my presence at all.
X
X - I could even support new writes to the VIR: media in this
X manner, where the destination was that of the current directory
X (and perhaps the top level was just a RAM disk).
X
XIssues to code:
X
X - (i should get positive ID info from learner, and stash it away)
X
X - Attempt to open a DOS device, and drop a packet into it. As
X a test I can have all the I/O to VIR: redirect itself in a
X natural manner to DR1:
X
X - Assignments do this, how? -> Probably have a device definition
X with a message structure also, and that receiving code fragment
X passes it along very much the way I want too. [ SB suggests this ]
X
X - Soooo... our emulation figures out the device name, positively
X attempts to identify it, (or requests it be brought online)
X i then find the message port of the device and patch the request
X through to it - in such a way that it doesn't return to me.
X
X - PipeHandler imbeds pipe specific commands into a device specific
X reference, like P:abc/def. What can I use that for?
X
X;-------------------------------------------------------------------------
XJan 18th 1991
X
X - It appears that the command "P:abc/def" gets passed in its
X entirety to the device driver (in Arg2 of the packet). This
X actually occurs because the shell is trying to execute that
X command. However at some earlier point the appropriate
X device has been determined, elsewise P: wouldn't have gotten
X the message...
X
X [ Pickpacket confirms this...DOS determines the device,
X nicely enough we get the 'VIR:' header with all files,
X (sometimes we may be on 'VIR' so it doesn't really help, or matter ]
X
X - lets see exactly what a "copy" command passes eh?
X
X [ not enuf (no source path (ARG!!))...but maybe we can hack it ]
X
X;-------------------------------------------------------------------------
XJan 18th 1991
X
Xediting new files on vir:
X VIR: generates a positive device ID and absolute file position using
X an internal default, be that your main harddrive, or ram:, vir: will
X always put the file at the root level, giving a unique numeric name
X appendum if file names collide (in which case you still refer to the
X vir: instance by its normal name). From that point on the file is
X treated as an ordinary existing file.
X
Xreading (existing) files on vir:
Xediting (existing) files on vir:
X all requests are passed to the appropriate device, using the
X positive device id and absolute file position info that vir keeps.
X
Xclosing edited files on vir:
X when you close a modified file vir: rebuilds that files checksums.
X
Xlearning (file aquisition):
X there is a "learn" command which acts exactly like "copy" as
X far as the user can tell. Internally passes a little bit of
X extra-info which specifies at the outset the files owner positive id...
X
X if it is possible the 'copy' command will be detected and changed
X to a 'learn'.
X
Xhow about copy from vir: to vir:?
X
X;-------------------------
X
Xx to vir: (new) -> either non-permissible or copy to default
Xx to vir: -> patch request to owner
Xvir: to vir: -> just copy reference (implicit or explicit?)
Xvir: to x: -> patch request to owner
Xx: to x: -> who cares
X
X;--------------------------------------------------------------------------
Xnew-file alternatives:
X
X 1) write to the media of which i am a sub dir of
X Not acceptable, because it destroys portability
X
X 2) copy to default, a poor but simple solution
X
X 3) copy with heirarchy if possible (so-so)
X 4) copy create heirarchy (so-so)
X 5) disallow (so-so)
X
X Best not to implement some arbitrary scheme lacking of exposure
X to mainframe virtual storage system solutions; so simpler is better.
X
X;----------------------------------------
X
Xanyway new file looks like a hassle; just disable for now, figure out later...
X
X
X;----------------------------------------------------------
Xjan 19th 1991
X
X ok so we're left with the issue of positive media identification
X
X fib_diskkey is what? NOT DOCUMENTED... SHIT
X
X hmmmm....
X
X;----------------------------------------------------------------
X
Xoperating on a positive id
X
X search device list for that device name
X if its a physical media type device then also search for positive id
X get message port of device
X
X I wonder how DOS does the search? does it forbid etc?
X
X;------------------------------------------
X
Xall i/o gets passed onto named device
X
X
X pull file id tag:
X "filepath/file-orig-name"
X device pointer (has device name, positive id if any, handle)
X
X open a message port with the device
X (just LOCK opened one up with us)
X
X;---------------------------------------------
X
Xhandling old stuff
X
X 1) packet request comes in
X 2) if management request then handle as normal
X 3) if i/o request then:
X - get device name, device positive id
X - get process identifier port
X struct MsgPort *pro = DeviceProc("df0:");/* example */
X - (or fail)
X - for now reissue the packet and wait, then reply
X - later pass packet verbatim to port, don't reply
X
X;---------------------------------------------------------------------------
X
X ACTION_OPENRW:
X ACTION_OPENOLD:
X ACTION_OPENNEW:
X - get pointer to devinfo
X - get msgport of named device, attach to handle
X - attach subdir to filename
X - patch request thru to device
X ACTION_READ:
X ACTION_WRITE:
X ACTION_CLOSE:
X ACTION_SEEK:
X - patch request thru to device (use handle messageport)
X ACTION_DIE:
X ACTION_EXAMINE_NEXT:
X ACTION_EXAMINE_OBJECT:
X ACTION_INFO:
X ACTION_DISK_INFO:
X ACTION_PARENT:
X ACTION_DELETE_OBJECT:
X ACTION_CREATE_DIR:
X ACTION_LOCATE_OBJECT:
X ACTION_COPY_DIR:
X ACTION_FREE_LOCK:
X ACTION_SET_PROTECT:
X ACTION_SET_COMMENT:
X ACTION_RENAME_OBJECT:
X ACTION_INHIBIT:
X ACTION_RENAME_DISK:
X ACTION_MORECACHE:
X ACTION_WAIT_CHAR:
X ACTION_FLUSH:
X ACTION_RAWMODE:
X - all act as normal
X
X
X- get pointer to devinfo
X- get msgport of named device, attach to handle
X must have devinfo available by pointer
X just call a gumby routine to return this vector
X
X- attach subdir to filename
X (don't bother for now)
X
X- patch request thru to device
X
X;--------------------------------------------------------------
X
XThe driver will have 2 modes
X
X1) RAMDISK Mode
X
X This is used to "learn" files
X
X The learn command submits "ordinary" files to save
X onto vir: thus any destination can be used for learn (ie: RAM:)
X
X All reads and writes simply operate on the RAMDRIVE as a RAMDRIVE
X
X2) Virtual Mode
X
X All reads and writes are patched through to their real owner
X
X A special check is performed to only accept VIR: type files
X
XCOMMENTS:
X
X a) VIRTUAL mode is always on as far as the client is concerned,
X learn triggers into RAMDRIVE mode, and then back out.
X
X b) There is a special user do-able way to goto RAMDRIVE MODE
X thus user can share files between different VIR:'s, or make
X a backup of the VIR: media.
X
X c) 'learn' is built directly into the DEVICE, issuing a LEARN
X command "makes" a learn function!
X
X or the command can be specified as one batch...
X
X 'learn_df0:mymedia_to_vir:myfile'
X
X if it accepts spaces then thats great!
X
X d) coalesce simply eliminates the second media reference of a
X pair which are the same...
X
X;-------------------------
XAMIGADOS TECH REF PAGE 268 !!!!!
X
X To distinguish disks with the same name
X AmigaDOS timestamps the volume on creation, then saves
X timestamp in list structure.
X
X
X
X new handler process per instance of df0:, each having
X own list struct, if not inserted then save-away any
X active locks + presumably VolDays...
X
X on reinsert then probably looks for VolDays, reattaches locks
X
X
X
Xlearn
X - build up dir,path,filename,checksums, type
X submit file as a packet to specified device
X
X;----------------------------------------------------------------------------
XSunday Jan 20 00:30
X
X ok so the learn is coded and works fine
X
X now:
X device gets incoming "open" request
X
X 1) search devinfo list for named device
X 2) possibly request media insertion
X (wait around till its inserted or aborted)
X (perhaps make it so that it won't be let go before step #5)
X 3) make sure that positive id matches
X 4) substitute entire path into lock
X 5) patch request to that device
X
X - need mode to switch between being ramdisk and being virtual
X 1) ram mode is just normal
X 2) virtual mode patches all read/write requests
X
X what are the trade offs of storing FIB info directly into
X RAM FIB struct versus keeping it as a file?
X - there is no ram fragmentation benefit either way
X (ie better ram solutions can be figured out for either)
X - RAM FIB might be faster (marginally)
X - file format: external modules like learn are simpler
X (excellent reason -> allows human handling, truckability)
X (also makes learn useful for non-internal enviroments)
X
X;------------------------------------------------------------------------
XJan 22 91
X
X ok so now the requests are being patched off to the proper handler
X but we're encountering a bug which I think goes like this:
X
X 1) client finds my process ID and submits a LOCK request
X 2) I patch the packet off to other process ID which returns LOCK
X 3) client passes LOCK to me for a read
X 4) I don't understand the lock because it isn't mine; failure.
X
X to prove if this is in fact the problem; I should patch ALL
X requests through, and see if I get a READ packet at all. If I don't
X then that suggests that the LOCK carries its own PROCESS ID, and that
X the bug lies elsewhere. IE the command READ is generic -> but
X we know thats not true because you must call the desired handler.
X
X If this is the problem then the solution is like so:
X
X 1) client finds my process and submits LOCK request (as before)
X 2) I submit same request to other process ID, and wait for reply.
X 3) On success I tag on my own info to the LOCK
X 4) client passes LOCK to me for a read
X 5) I check to see if my OWN info is appended
X 6) If so then I patch LOCK onto other process
X
X So the issue is that the OPEN and READ requests are both going to
X come to me; and I'll need some conscious bridge to remember if I
X opened it; and which device I opened it of.
X
X I think all I need to stash in the LOCK is the actual device process.
X
X It would be nicer if all the low level AMIGADOS functions extracted
X process ID from the lock itself, rather than making that a user
X responsibility. This is the root of the problem.
X
X Basically I'm just acting as a DEVICE ARBITRATOR - - - I can think
X of the process as 2 parts:
X
X 1) Determining destination DEVICE
X 2) Patching *ALL* related requests to that device.
X
X In my code the process seems a bit cloudy because on the OPEN I
X do both more or less atomically. I should seperate these out to
X make the relationship more clear. Possibly having a flag which
X states if this request is to be specially reserved as a patch request.
X
X So in that case do I really have to wait for an ACK from the OPEN?
X
X Somehow if I could stash my information directly into the initial
X LOCK I would be freed of the responsibility of having to intercept
X and reply to any packets, I could just pass them straight on.
X
X Of course it is true that the initial packet must also be modified,
X and anyway there is a solution, and it looks as if things like
X getting the initial LOCK back so I can patch it, and modifying the
X submitted packet in the first place are going to prevent me from
X having an idealized solution for the OPEN request anyway. All the
X other requests can be straight patches presumably.
X
X Ok so now lets test if my initial premise is correct. I'll do
X this by patching all requests so my ramdisk justs acts like a debugger
X peeking into packet transit between two other entities.
X
X [ YES - the premise appears to be correct; with some qualifications ]
X
X 1) The reason I didn't see any READ's before when I attempted this
X is because I forgot, I'm supposed to be addressing the VIR device.
X
X 2) There seems to be some kind of general LOCK going on, right away
X
X 3) The LIST and DIRECTORY commands only require 1 access? WHY?
X This is very important to figure out. I can't understand why
X I am not getting an EXNEXT?
X
XLets look at 3
X
X We get a Packet 8 -> LocateObject
X It returns a LOCK
X
X *** Presumably the LOCK has the MESSAGE PORT in it ALSO ***
X
X Interestingly enough "list" never releases the LOCK it gets
X (probably bound up with directory stuff...)...Or something like
X it -> It does act normally if you're not ON the device, but if you
X are local to it then it *knows* about the lock already available,
X and simply uses it?
X (hmmm...actually maybe 'list', 'ls' and 'dir' act the same)
X
X anyway so if you're on VIR and you do a DIR where all requests are
X being transfered over to DR1: VIR won't get any packet requests at
X all -> presumably because the device is LOCKED and the LOCK is
X cached *and* the lock has a copy of the message port.
X
X [ yes ] that appears to be correct -> the lock does have the msg port.
X
X Ok so lets review everything again:
X
X 1) we're going to patch thru all I/O packets by extracting
X some special info we hide in the FileHandle at OPEN Time
X (because they call me multiple times).
X
X 2) all directory and lock related stuff we normally just
X handle ourselves, but if we wanted to patch them through
X then we would just patch them and forget them...thats all.
X If somehow somebody doesn't use the LOCK port, but the
X original PORT (me) then that gets patched also anyway so
X there is no chance for collision. If they request a
X file handle based on incorrect information...well I just
X return "file not found"...no problems...
X
XSo step 1) is the most important; Is the earlier scheme the best way?
X
X1 well the I/O can either use my FileHandle with their Port and
X handle hidden in it -> and if user modifies my handle then I
X modify theirs in kind
X
X2 Or I stash my info into their FileHandle and hope that they don't
X trash it.
X
X3 Or I create a Hybrid handle of my own, which stashes their port
X and handle, as in the first case, but continually re-updates it?
X Or is this functionally equivilant to case 1?
X
XI suspect the solution is a combination of the above methods...
X
X;----------------------------------------------------------------------------
X
XThe way DOS works:
X
X
XLocate.Object
X parameters:
X lock on parent director or NULL (root)
X name of file
X comments:
X presumably there is implicit the parameter of the correct device
X it requires no parameters other than name in a minimum case,
X this is why I would refer to it as the "bootstrap" entry gate.
X
XOpen Old File
X parameters:
X Lock on its directory (may be zero = root)
X Name
X comments:
X now it fills up your filehandle (passed by reference)
X
X*** lets look at my vir again:
X
X client submits an "open" request keyed to the VIR subdir LOCK
X that the file is apparently in.
X
X i want to now open of another device in another directory,
X but i have to submit the parent lock apparently;
X
X i don't see why i can't directly open a file in a sub dir.
X
X my ACTION_OPEN doesn't support it though (hmmm...I guess the
X driver doesn't know about the idea of directories).
X
X (so what do you get if you submit a subdir???...1) either the
X whole thing is submitted -OR- there are multiple calls to
X tradverse the layers; check out now please.
X
X [ the lock was submitted cold - with a parent lock of 0 ]
X
X ie:
X
X 1> list subdir/mydir/myfile
X [ resultant issued packet = 8 args: LOCK,LOCK,MODE ]
X
X 1> list :subdir/mydir/myfile
X [ resultant issued packet = 8 args: 0,LOCK,MODE ]
X
X This suggests that at least for the examine function the DEVICE
X does understand directory structures, (thus making life much
X easier for me) now lets check READ:
X
X 1> type :subdir/mydir/myfile
X [ result = packet 1005 args: FileHandle,0,Name ]
X
X 2> type subdir/mydir/myfile
X [ result = packet 1005 args: FileHandle,LOCK,Name ]
X
X Ok thats great! So everything works same as before, but i should
X make sure to clear the lock field of the open file request (although
X I understand that Matts handler is performing the extra duty, and
X in fact other handlers might not bother... - To be on the safe
X side I might want to just steal the ':' LOCK from the DevInfo struct.
X
X *** but actually I know that I don't have to do that *because* its
X not Matts handler issuing the quasi-legal request, but other
X programs...so its quite obvious that a 0 LOCK is supported ***
X
XAre there any ramifications here about locking the device? (so somebody can't
Xremove it from the system on me?)
X
X
Xok so lets cover everything again....
X
X0) client is browsing around in vir:
X
X1) all directory handling and renaming is supported right in the handler
X - acting in its RAMDRIVE way.
X
X2) the examine command is mostly normal except it does a tiny bit of
X extra work and returns the indirect file size rather than the ramdrives' file size.
X
X3) the open_new command we haven't dealt with, or vir to vir copy also.
X
X4) the open_old figures out and accesses the device (perhaps asking that
X it be brought online) and gets a file handle on the file. It
X retains the device message port, and the device and file lock. the
X client gets back what appears to be a handle on the actual file. The
X open is structured in source in such a way as that it can rely on
X (as its second) the same routine that the read/write routine relys on.
X
X5) the read/write commands (yes write is supported even if open_new isnt)
X pass the requests onto the real device; based on message port info
X and the proper device lock and file lock.
X
X in general all modifications to the lock or filehandle are carried
X through by vir: the ultimate mediator.
X
X6) learn commands, coalesce, load and save database, turn off the
X virtual mode of the driver momentarily (process relative to
X their own operation only) and treat vir: as an ordinary ramdisk.
X
X;-------------------------------------------------------
XJan 23 91
X
X An alternative to the entire scheme discussed above is the following:
X
X Intercept the calls to _LVOOpen, _LVORead, _LVOWrite (one level up)
X
X such that when the system searched for a particular file, it would
X find it - except that the device would be different.
X
X I would watch and intercept calls to _LVOOpen accessing "vir:"
X and remap them over based on my internal database
X
X perhaps this was the better way...but oh well I'm to far into it now.
X
X;--------------------------------------------------------------------
XFeb 1 91
X
Xok so the vir: device is working now, we can do the following:
X
X - learn new files (should csum each key, assign media #'s)
X - virtually access files (should lock subdir if name >128)
X
X now we need to deal with:
X
X - coalesce intelligently (or just find duplicates)
X - writing new files to vir:
X
XNEW FILES:
X just write to dh0: with a datestamp unique name.
X (or just write to VIR: as a non-virtual file)
X
XCOALESCE
X - accept wildcard source, wildcard dest
X - compare all sources to all dests
X - retag dests (copy one to the other) or just print dup addrs
X
X;---------------------------------------------------------
Xmarch 2 1991
X tidied up vir: a bit, more robust
X determined that the FIB_PADDING or FIB_RESERVED is really and
X truly RESERVED unfortunately....I'm currently using the comment
X field, but I'll have to think more about it.
X
X wrote a coalesce based on 'du' from Stuart Mitchell
X
X now trying to make coalesce be smart about its directory
X comparison...not every compare the same file twice
X and do so implicitly - by copying the anchor chain, and
X searching next file on as a comparator...not all files again..
X
X ...wait! i can't do that...cause src and dest are not
X neccessarily the same...i guess i could have an optimized mode
X (anyway i couldn't get it to work so....)
X
X
END_OF_FILE
if test 32366 -ne `wc -c <'virt_mine.doc'`; then
echo shar: \"'virt_mine.doc'\" unpacked with wrong size!
fi
# end of 'virt_mine.doc'
fi
echo shar: End of archive 3 \(of 4\).
cp /dev/null ark3isdone
MISSING=""
for I in 1 2 3 4 ; do
if test ! -f ark${I}isdone ; then
MISSING="${MISSING} ${I}"
fi
done
if test "${MISSING}" = "" ; then
echo You have unpacked all 4 archives.
rm -f ark[1-9]isdone
else
echo You still need to unpack the following archives:
echo " " ${MISSING}
fi
## End of shell archive.
exit 0
--
Mail submissions (sources or binaries) to <amiga@uunet.uu.net>.
Mail comments to the moderator at <amiga-request@uunet.uu.net>.
Post requests for sources, and general discussion to comp.sys.amiga.misc.