home *** CD-ROM | disk | FTP | other *** search
/ Amiga Developer CD v1.2 / amidev_cd_12.iso / reference / amiga_mail_vol1 / dos / harddiskii < prev    next >
Text File  |  1990-01-26  |  18KB  |  492 lines
  1. (c)  Copyright 1989 Commodore-Amiga, Inc.   All rights reserved.
  2. The information contained herein is subject to change without notice, and 
  3. is provided "as is" without warranty of any kind, either expressed or implied.  
  4. The entire risk as to the use of this information is assumed by the user.
  5.  
  6.                            Setting Up Your Hard Disk
  7.                               for WorkBench V1.3
  8.                                    Part II
  9.  
  10.                                by Bill Koester
  11.  
  12.  
  13. Part I of this article dealt with the physical details of setting up a hard 
  14. drive and the related system software.  This article covers how to install 
  15. your application software for the best results. 
  16.  
  17. If you followed the guidelines in Part I, you now have a hard disk divided 
  18. into two partitions, dh0: and fh0:.  The fh0: partition should have all the 
  19. system software on it but ONLY ONE user directory, namely fh0:user.  The idea 
  20. is to isolate system software from application software in order to make 
  21. upgrades, backups and file recovery as simple as possible.  Use the standard 
  22. startup sequences on fh0:, but make the following two changes.  First, add
  23. these lines to fh0:s/startup-sequence just before the loadwb command:
  24.  
  25.       IF EXISTS SYS:user/user.startup-sequence
  26.          execute sys:user/user.startup-sequence
  27.       ENDIF
  28.  
  29. Second, add these lines to fh0:s/shell-startup:
  30.  
  31.       IF EXISTS SYS:user/user.shell-startup
  32.          execute sys:user/user.shell-startup
  33.       ENDIF
  34.  
  35.  
  36. With this arrangement, all application files are isolated in the SYS:user
  37. directory.  Any additions to the startup-sequence or shell-startup files 
  38. neccessary for a particular application can be made in the user versions
  39. (SYS:user/user.startup-sequence and SYS:user/user.shell-startup) since 
  40. they will now be executed automatically by the main startups.
  41.  
  42. Keeping user software isolated in its own directory makes it easier to back 
  43. up and easier to restore.  If you make regular backups of the SYS:user 
  44. directory you can feel confident of your ability to reformat and properly 
  45. restore the system - simply reinstall the system (as in Part I of this 
  46. article) and then copy the files from your backup to the SYS:user 
  47. directory.
  48.  
  49. For more security, you could make two partitions - one for system files and 
  50. the other for user files - then use the V1.3 Lock command to protect the 
  51. system directories from over-writing.  That way you can be sure you will not 
  52. change them.
  53.  
  54.  
  55. Applications
  56.  
  57. Separating system files from user files makes it easier to manage your hard 
  58. disk.  It is also easier if you keep the user files separate from each other.
  59. Many applications need assignments or paths for their directories.  These are 
  60. usually made in the main startup file but this makes moving or deleting an 
  61. application difficult once it has been installed. 
  62.  
  63. For instance, suppose you have several applications that need special assigns.
  64. You could put these assigns in the user.startup-sequence, but if you do it this
  65. way, as you add applications, the user.startup-sequence could become too large 
  66. to easily edit or understand.  If you decide to move or delete a directory 
  67. with paths or assigns to it, you will first have to remove all references to 
  68. that directory from the user.startup-sequence, reboot the machine and then 
  69. remove the directory.
  70.  
  71. A much better way is for the applications to do their own startups.  That way,
  72. the special assigns and paths that an application needs can be stored with 
  73. the application itself instead of in some generic, catch-all startup-sequence 
  74. in some other directory.
  75.  
  76.  
  77.  
  78. The Config Program
  79.  
  80. This is the purpose of the utility program Config.  With Config you can create
  81. a master startup-sequence which will call a local startup for each application 
  82. in turn.  Config will automatically write the master startup script for you.
  83. The command format for Config is:
  84.  
  85.       Config Directory OutFile SearchName
  86.  
  87. Config will search a given directory and all its sub-directories for files with
  88. the given name.  Each time it finds a match, Config will write these two lines 
  89. to a separate file you specify:
  90.  
  91.    cd Device:Dir/Dir/Dir
  92.    execute Device:Dir/Dir/Dir/Filename
  93.  
  94. The first line is a CD to the directory where the file was found.  The second 
  95. line executes the file as a script while CD'ed to its directory.  Adding these 
  96. two lines to a script will cause it to pass control to another script and then
  97. return when that script is done.  For instance assume the following directory 
  98. structure on fh0:
  99.  
  100.                    SYS:user(dir)
  101.                    /           \
  102.                   /             \
  103.            SuperPaint(dir)    SuperC(dir)
  104.              .startup
  105.  
  106. The directory SYS:user contains two subdirectories. The subdirectory SuperPaint
  107. contains the file .startup.  If you give the following Config command:
  108.  
  109.       Config SYS:user SYS:user/user.startup-sequence .startup
  110.  
  111. then Config will search all of SYS:user looking for files named .startup.  When
  112. Config finds SYS:user/SuperPaint/.startup it will add these two lines to the 
  113. SYS:user/user.startup-sequence file:
  114.  
  115.       cd SYS:user/SuperPaint
  116.       execute SYS:user/SuperPaint/.startup
  117.  
  118. Now when the system boots, s:startup-sequence will call sys:user/user.startup-
  119. sequence which will now call sys:user/SuperPaint/.startup and any other 
  120. .startup files found in the sys:user directory.
  121.  
  122. You can use the same method to add a separate shell-startup script file, called
  123. .shell, for each application with the following Config command:
  124.  
  125.       Config SYS:user SYS:user/user.shell-startup .shell
  126.  
  127. These two Config commands will take care of any set up needed for all
  128. applications as long as they have local scripts called .startup and .shell.
  129. For my system I made an IconX script so that these two lines execute from an 
  130. icon on my hard drive.  This is convenient, as you will see, since you have to
  131. reconfigure your system whenever you add or delete directories that had paths
  132. or assigns to them.
  133.  
  134. Now let's consider the contents of the local .startup and .shell scripts. 
  135. Config requires us to write position-indpendent scripts.  This means that any
  136. .startup or .shell script should work regardless of its physical position in 
  137. the file system.  Let's take SuperPaint as an example.
  138.  
  139. Suppose that SuperPaint needs the assignment SuperPaint: to function properly 
  140. and that you would also like to add a path to its directory so you can execute 
  141. it from the CLI.  You could use this script:
  142.  
  143.       assign SuperPaint: sys:user/superpaint
  144.       path               sys:user/superpaint
  145.  
  146. However, this is not the best solution.  If you decide to move the SuperPaint 
  147. directory to sys:user/Paint/SuperPaint, this script won't work anymore because 
  148. the absolute paths are wrong.  However, if you write the script as:
  149.  
  150.       assign SuperPaint /SuperPaint         ;You could use "" instead of 
  151.       path              /SuperPaint add     ;/SuperPaint to mean "right here"
  152.       echo "SuperPaint"
  153.  
  154. then the script will work regardless of its position.   The echo command is 
  155. used here to show what is being configured and in what order.  
  156.  
  157. The .shell files are similar to .startup files except that they get executed 
  158. every time a new shell is opened.  I use .shell files to configure my source 
  159. code directory.  For example, the .shell for my source directory is:
  160.  
  161.       alias ls dir
  162.       alias mv rename
  163.       stack 50000
  164.       cd src:config
  165.  
  166. Each time I open a new shell, the above aliases are entered, my stack is set
  167. to 50000 bytes and I wind up CD'ed to my working directory.  If I change 
  168. projects, I can edit my .shell file to CD me to the right directory.
  169.  
  170. Using Config in this way, all information needed to set up an application is 
  171. kept in the same directory as the application.  There is still one problem
  172. with this scheme though - and that is how to handle paths to system directories
  173. that may be needed.  Hopefully a future operating system release will allow
  174. multiple paths for system directories, such as:
  175.  
  176.       assign fonts: sys:fonts                ;First path...
  177.       assign fonts: sys:user/app1/fonts add  ;this command does not exist yet
  178.  
  179. You can begin to plan for this now.  For example, if an application needs 
  180. fonts, you can modify the .startup file for the application by adding the 
  181. following:
  182.  
  183.      IF NOT EXISTS fonts:my_app_font  ;Check if a local font has been copied
  184.         copy fonts fonts:             ;if not, copy all fonts from here to the
  185.      ENDIF                            ;main fonts: directory
  186.  
  187. If this is the .startup file for SuperPaint and the directory SuperPaint/fonts 
  188. exists, then the above script fragment will copy the application-specific fonts
  189. to the system's font directory  where they can be found by all.  The script 
  190. will only copy the fonts if they have not already been copied .  This will
  191. cut down on the user waiting time since these scripts are executed every time 
  192. the system boots.
  193.  
  194.  
  195. Maintenance
  196.  
  197. If you follow the arrangement above, then your system files are separated from
  198. your applications in SYS:user.  Each application has its own sub-directory with
  199. .startup and .shell files if needed.  You also have an IconX script which will 
  200. create the master startup that calls on each application's local .startup file
  201. in turn.  For system maintenance you should also make a IconX script that 
  202. deletes the two files SYS:User/user.startup-sequence and SYS:User/user.shell-
  203. startup.  Maintenance involves three basic operations: adding, deleting and 
  204. moving applications.
  205.  
  206.  
  207. Adding
  208.   
  209. To add a new application, make a directory for it in SYS:user or below.  Copy 
  210. the application files to the new directory and create a .startup file if the 
  211. application needs fonts, libs, assigns, paths or any other set-up that only 
  212. needs doing once.  Next create a .shell file if one is needed (most software
  213. can be configured without a .shell).  Now to install the application into the 
  214. system simply click on the IconX script that makes the master startup.  The 
  215. old user.startup-sequence and user.shell-startup will be overwritten with the 
  216. new copy.
  217.  
  218.  
  219. Deleting
  220.  
  221. Since it is not possible to delete a directory that has current assigns or 
  222. paths associated with it, you must first remove the assigns and paths.  To do
  223. this, click on the IconX script that deletes the SYS:User/user.startup-sequence
  224. and SYS:User/user.shell-startup files.  Now reboot the Amiga.  Since the files
  225. no longer exist, the assign and paths will not be set and you can delete the 
  226. application with:
  227.  
  228.            delete sys:User/SuperPaint#? all quiet
  229.  
  230. After the desired applications have been removed click on the Config IconX 
  231. script to reconfigure the applications that remain.   Now reboot and 
  232. everything will be in order.
  233.  
  234.    
  235. Moving
  236.  
  237. To move an application directory, follow the same rules as for deletion, but 
  238. instead of deleting the directory after the first reboot, use rename to move 
  239. it to another part of the same partition or use copy to move it to another 
  240. drive (rename does not work across devices).  Then delete the old copy of the
  241. application, reconfigure and reboot.
  242.  
  243.    
  244. Editing
  245.  
  246. You can edit .startup and .shell files without reconfiguring.  But you will 
  247. have to reboot to activate the changes you have made to a .startup.  For .shell
  248. files, just close and reopen any shell windows and the changes will take effect.
  249.  
  250.  
  251. As you can see the Amiga's user environment can be complicated.  I hope the
  252. information given here takes some of the hassle out of setting up your hard 
  253. drives.  By following the procedures here upgrades, backups and restoring 
  254. files will be easier.  You can extend these procedures for more than one 
  255. hard disk, or even to a network.
  256.  
  257.  
  258.  
  259. ------------------------ Lauren, code starts here ---------------------
  260.  
  261.  
  262. /*********************************************************************/
  263. /*                                                                   */
  264. /* Config.c - Hard Drive Configure Utility by Bill Koester (CATS)    */
  265. /*                                                                   */
  266. /*********************************************************************/
  267.  
  268. /* Runs from the CLI only */
  269.  
  270. #include <exec/types.h>
  271. #include <intuition/intuition.h>
  272. #include <libraries/dos.h>
  273. #include <libraries/dosextens.h>
  274.  
  275. int  gargc;
  276. char *gargv2;
  277. char *gargv3;
  278.  
  279. main(argc,argv)
  280. int argc;
  281. char *argv[];
  282. {
  283.  
  284.    int      Error          = 0;
  285.    struct   FileLock *lock = 0;
  286.    struct   FILE     *fp   = 0;
  287.  
  288.    /*********************
  289.     * Usage Information
  290.     *********************/
  291.    if(argc!=4) {
  292.       printf("\nConfig Version 1.0 by Bill Koester (CATS)\n");
  293.       printf("Usage:\n");
  294.  
  295.       /*             argv[0]   [1]      [2]       [3]    */
  296.       printf("       Config Directory OutFile SearchName\n\n");
  297.       Error=5;
  298.       goto Cleanup;
  299.    }
  300.  
  301.    /******************************
  302.     * Initialize globals (yikes!)
  303.     ******************************/
  304.    gargc=argc;
  305.    gargv2=argv[2];
  306.    gargv3=argv[3];
  307.  
  308.    /*************************
  309.     * Get lock on directory
  310.     *************************/
  311.    if((lock=(struct FileLock *)Lock(argv[1],ACCESS_READ))==0)
  312.    {
  313.       printf("Could not get lock on %s\n",argv[1]);
  314.       Error=5;
  315.       goto Cleanup;
  316.    }
  317.  
  318.    /*************************
  319.     * Open output file
  320.     *************************/
  321.    if((fp=(struct FILE *)fopen(argv[2],"w+"))==0)
  322.    {
  323.       printf("Could not open file %s\n",argv[2]);
  324.       Error=5;
  325.       goto Cleanup;
  326.    }
  327.  
  328.    /***************************************************
  329.     * Recursive routine to do this dir and all subdirs
  330.     ***************************************************/
  331.    DoDir(lock,fp);
  332.  
  333. Cleanup:
  334.    if(lock) UnLock((BPTR)lock);
  335.    if(fp) fclose(fp);
  336.  
  337.    return(Error);
  338. }
  339. /***********************************************************************
  340.  *
  341.  * DoDir(lock,fp)
  342.  *
  343.  * Starting at the 'lock'ed directory search all subdirectorys
  344.  * for files with the name pointed to by gargv3. for each file found
  345.  * write to the file whose name is pointed to by gargv2.
  346.  *
  347.  ***********************************************************************/
  348. DoDir(lock,fp)
  349. struct FileLock *lock;
  350. struct FILE     *fp;
  351. {
  352.    struct FileInfoBlock *FIB;
  353.    struct FileLock      *OldLock;
  354.    struct FileLock      *TempLock;
  355.    int    Error =0;
  356.  
  357.  
  358.    OldLock=(struct FileLock *)CurrentDir((BPTR)lock);
  359.  
  360.    /**************************
  361.     * Allocate a FileInfoBlock
  362.     **************************/
  363.    if((FIB=(struct FileInfoBlock *)AllocMem(sizeof(struct FileInfoBlock),0))==0)
  364.    {
  365.       printf("Could not allocate memory for FIB\n");
  366.       Error=5;
  367.       goto Cleanup;
  368.    }
  369.  
  370.    /*******************
  371.     * Set up for ExNext
  372.     *******************/
  373.    if(Examine((BPTR)lock,FIB)==0)
  374.    {
  375.       printf("Examine failed\n");
  376.       Error=5;
  377.       goto Cleanup;
  378.    }
  379.  
  380. more:
  381.    /*********************************************
  382.     * If no more entries in this branch then exit
  383.     *********************************************/
  384.    if((ExNext((BPTR)lock,FIB)==0)&&(IoErr()==ERROR_NO_MORE_ENTRIES))
  385.       goto exit;
  386.  
  387.    /**********************
  388.     * Is this a directory?
  389.     **********************/
  390.    if(FIB->fib_DirEntryType>0)
  391.    {
  392.       /**************************
  393.        * Yes, get lock on new dir
  394.        **************************/
  395.       if((TempLock=(struct FileLock *)Lock(FIB->fib_FileName,ACCESS_READ))==0)
  396.       {
  397.          printf("DoDir could not get a lock!\n");
  398.       }
  399.       else
  400.       {
  401.          /*****************************************************
  402.           * Call DoDir recursively to process the new directory
  403.           *****************************************************/
  404.          DoDir(TempLock,fp);
  405.          UnLock((BPTR)TempLock);
  406.       }
  407.    }
  408.    else
  409.    {
  410.       /***********************************
  411.        * No, It's a file so check its name
  412.        ***********************************/
  413.       if(stricmp(gargv3,FIB->fib_FileName)==0)
  414.       {
  415.          /**********************************************
  416.           * We have a match so write an entry to OutFile
  417.           **********************************************/
  418.          fprintf(fp,"cd ");
  419.          PrintCurrentDir(lock,fp);
  420.          fseek(fp,-1L,1);           /* Remove trailing backslash */
  421.          fprintf(fp,"\n");
  422.  
  423.          fprintf(fp,"execute ");
  424.          PrintCurrentDir(lock,fp);
  425.          fprintf(fp,gargv3);
  426.          fprintf(fp,"\n");
  427.       }
  428.    }
  429.    goto more;
  430.  
  431. exit:
  432.  
  433. Cleanup:
  434.    CurrentDir((BPTR)OldLock);
  435.    if(FIB) FreeMem((char *)FIB,sizeof(struct FileInfoBlock));
  436.    return(Error);
  437. }
  438.  
  439. /************************************************************************
  440.  *
  441.  * PrintCurrentDir(lock,fp);
  442.  *
  443.  * Prints to the file  fp the full path name for the entity associated with
  444.  * 'lock'. This function is also recursive.
  445.  ************************************************************************/
  446. PrintCurrentDir(lock,fp)
  447. struct FileLock *lock;
  448. struct FILE     *fp;
  449. {
  450.    struct FileLock *parent;
  451.    struct FileInfoBlock *FIB;
  452.  
  453.    /************************
  454.     * Allocate FileInfoBlock
  455.     ************************/
  456.    if((FIB=(struct FileInfoBlock *)AllocMem(sizeof(struct FileInfoBlock),0))==0)
  457.    {
  458.       printf("PrintCurrentDir could not allocate memory for FIB!\n");
  459.       goto Cleanup;
  460.    }
  461.  
  462.    /**************************************************************
  463.     * If there is no parent for this lock then we have the volume
  464.     * and our base case.
  465.     **************************************************************/
  466.    if((parent=(struct FileLock *)ParentDir((BPTR)lock))==0)
  467.    {
  468.       /*******************
  469.        * Print volume name
  470.        *******************/
  471.       Examine((BPTR)lock,FIB);
  472.       fprintf(fp,"%s:",FIB->fib_FileName);
  473.       goto Cleanup;
  474.    }
  475.    /**************************************************
  476.     * Recursively print the parent of the current lock
  477.     **************************************************/
  478.    PrintCurrentDir(parent,fp);
  479.    UnLock((BPTR)parent);
  480.  
  481.    /*****************************************
  482.     * Then tack the current lock onto the end
  483.     *****************************************/
  484.    Examine((BPTR)lock,FIB);
  485.    fprintf(fp,"%s/",FIB->fib_FileName);
  486.  
  487. Cleanup:
  488.    if(FIB) FreeMem((char *)FIB,sizeof(struct FileInfoBlock));
  489.    return(0);
  490. }
  491.  
  492.