home *** CD-ROM | disk | FTP | other *** search
/ DP Tool Club 8 / CDASC08.ISO / VRAC / ULP100.ZIP / Q&A.DOC < prev    next >
Text File  |  1993-08-28  |  13KB  |  259 lines
  1.  
  2.     ┌───────────────────┐
  3.     │                   │ ║
  4.     │    ╥   ╥ ╥        │ ║                UpLoadProcessor
  5.     │    ║   ║ ║ ╓──╖   │ ║
  6.     │    ║   ║ ║ ║  ║   │ ║
  7.     │    ╙───╜ ╨ ║──╜   │ ║          Answers to Common Questions
  8.     │            ╨      │ ║
  9.     └───────────────────┘ ║
  10.       ════════════════════╝
  11.  
  12.  
  13. The following are some frequently-asked questions extracted from my support
  14. conference, which may answer questions or problems you may have with ULP:
  15.  
  16. QUESTION:  A file was uploaded to my board, and was failed for duplication and
  17.     renamed to .DUP. But, it wasn't really a dupe, but just a really similar
  18.     update, so I renamed it to .ZIP, and changed the entry to .Zip in the uldir
  19.     file, as well.
  20.  
  21.     Unfortunately, the next time I ran ULP, it processed it as a brand new file
  22.     again and renamed it to zip again.  Evidently, files that are rejected by
  23.     ULP.EXE do not get put into the process.dat file, and will be processed
  24.     over and over again ad infinitem?
  25.  
  26. ANSWER:  ULP entered the filename xxxxxxxx.DUP in the process data file. As far
  27.     as ULP is concerned, when you renamed it to .ZIP, it became a new file to
  28.     be processed. This is by design.
  29.  
  30.     You should have done one of two things. Run ULP.EXE in override mode (-O
  31.     command line parameter), without renaming the .DUP file, which would
  32.     process all new files and reprocess all failed files without regard to age
  33.     or duplication. This is good for a large number of .AGE and .DUP files that
  34.     you want to process at once, not to mention the files are converted,
  35.     recompressed, commented, BBS ads removed, etc.
  36.  
  37.     Alternatively, after you renamed the .DUP to .ZIP in the upload area, you
  38.     could have reinitialized the process data file to correctly enter the
  39.     renamed filename. This is probably simpler when renaming one or two files,
  40.     but does not yield the benefit of conversion, recompression, et al.
  41.  
  42.  
  43. QUESTION:  I installed the new beta and uploaded (locally) FILENAME.ZIP and
  44.     again, it failed with "failed file checking [exit code 2]".
  45.  
  46. ANSWER:  The information in the brackets is the errorlevel that was returned to
  47.     ULPTEST (and ULP as well) by the external process. You need to look in the
  48.     documentation for the file checker that failed, and see what error code 2
  49.     is. The reason I've added that information to the logs is to allow sysops
  50.     to better debug their setups.
  51.  
  52.  
  53. QUESTION:  I have a problem with ZDCS and ULP where ULP calls up ZDCS but the
  54.     duplication database doesn't get updated. I am using the latest version of
  55.     both your programs. I can upload the same file 10 times an it passes each
  56.     time.
  57.  
  58. ANSWER:  Your problem is that you are not running in the correct mode of
  59.     operation. Only ULPTEST's SLOW mode updates the database in real time. When
  60.     run in NORMAL mode, ULPTEST only test files, but does not repack or update
  61.     the database. In the event, ULP.EXE will reprocess all new files run in
  62.     NORMAL or FAST modes, repacking them and updating the ZDCS database. This
  63.     is part of the sigificant speed increase in running NORMAL and/or FAST mode
  64.     versus SLOW.
  65.  
  66.  
  67. QUESTION: I want to be able to get the message at the bottom of the description
  68.     that there are Files:X Bytes:Z Newest:J Oldest:Y.  I left the default
  69.     configuration that came with the ULP file but it does not show up.
  70.  
  71. ANSWER:  The information lines are inserted ONLY by ULP.EXE in the event and/or
  72.     by ULPTEST.EXE when in SLOW mode. If you are running ULPTEST in FAST or
  73.     NORMAL modes, the line will be inserted during the event.
  74.  
  75.  
  76. QUESTION:  Files that fail for duplication and/or age are not being renamed.
  77.     What's wrong?
  78.  
  79. ANSWER:  Only ULP.EXE will rename failed files. PCBoard does not permit the
  80.     renaming of uploads during testing.
  81.  
  82.  
  83. QUESTION:  FILE_ID.DIZ and DESC.SDI files are not being inserted by ULP after
  84.     uploading. Nor is ULPTEST is processing the FILE_ID.DIZ files within zips
  85.     that have subdirectories.  It passes and posts the file, but without
  86.     converting the .DIZ into a description.
  87.  
  88. ANSWER:  ULPTEST FAST mode is unable to insert any FILE_ID.DIZ or DESC.SDI
  89.     files within the upload since it does not unpack the archive. Remember that
  90.     FAST mode is a direct scan of the archive headers, and since the internal
  91.     description file is not physically available, ULPTEST cannot insert it. As
  92.     for the archives with subdirectories, when ULPTEST encounters an archive
  93.     with dissimilar paths, it automatically changes to FAST mode.
  94.  
  95.     However, when reprocessed by ULP.EXE in the event, the internal description
  96.     file will then be inserted.
  97.  
  98.  
  99. QUESTION:  I have intermittent lockups in ULP. Usually the last message on the
  100.     screen is "Swapping in" or "Swapping out".
  101.  
  102. ANSWER:  Swapping can be very tricky, and may be allergic to some systems.
  103.     Swapping ULP and ULPTEST only yields another 85K or so of memory, and if
  104.     you do not absolutely have to have that memory, it would be best to not
  105.     use swapping, for stability and speed concerns.
  106.  
  107.  
  108. QUESTION:  I use a 8 meg ram disk and it will tell my users on occasion that
  109.     error work space something. But anyways i have 8 meg in there and it is
  110.     usually a file that is being sent that is around 1400k in size...
  111.  
  112. ANSWER:  The ULP programs now better checks for available disk space prior to
  113.     unpacking, and if a file is too big (there must be 5 times the file size
  114.     *available*), it will be failed for insufficient work space. Note that FAST
  115.     mode eliminates this problem...I would strongly suggest setting the normal
  116.     mode limit to something less than 1/5 of your available work drive space.
  117.     In your case, set the normal limit to around 1200K or so.
  118.  
  119.  
  120. QUESTION:  I get errors of "Can't access process data file", but I can
  121.     initialize it using ULP and ULPSM.
  122.  
  123. ANSWER:  You must include paths for files and subdirectories. The ULP programs
  124.     are very complex, and move around your drives in order to process the files
  125.     and subdirectories configured. If you supply only a filename or a relative
  126.     path, it may or may not work. For all configuration options, include a full
  127.     path, including the drive letter; do not simply enter a filename.
  128.  
  129.  
  130. QUESTION:  It seems that if I am using the 3 dir setup (like originally
  131.     suggested),  my files get processed by ulptest from the private to the
  132.     upload directories just fine. It's ok, just so I know to get rid of my
  133.     ulpfull (fully processed uploads) directory, and set up ulp to process the
  134.     two directory setup.
  135.  
  136. ANSWER:  You probably have the directories crossed. If you want to run the old
  137.     3-directory setup (some do for intermediate, non-ULP processing), you need
  138.     to have it as follows:
  139.  
  140.         PCBSETUP Designation      Subdirectory      ULP Designation
  141.         --------------------      ------------      ---------------
  142.         Private                   C:\PRIVATE
  143.         Public                    C:\PARTIAL        Source
  144.                                   C:\COMPLETE       Destination
  145.  
  146.     If a file passes test, it will be moved by PCBoard from the C:\PRIVATE
  147.     subdirectory to the C:\PARTIAL subdirectory. Upon event processing, ULP
  148.     will move the good files from the C:\PARTIAL to the C:\COMPLETE
  149.     subdirectory. You must have all uploads set to public in PCBSETUP for this
  150.     to work. Failed files will be contained in C:\PRIVATE or C:\PARTIAL,
  151.     depending upon when they failed.
  152.  
  153.     As for the other setup concepts, this is in the docs, but I'll try to
  154.     explain it again...
  155.  
  156.     If you want to run with a 2-directory setup, you must make all uploads
  157.     *private* in PCBSETUP. The subdirectories will look like:
  158.  
  159.         PCBSETUP Designation      Subdirectory      ULP Designation
  160.         --------------------      ------------      ---------------
  161.         Private                   C:\PRIVATE        Source
  162.         Public                    C:\PUBLIC         Destination
  163.  
  164.     Regardless of the results of file testing, uploads will be left by PCBoard
  165.     in the C:\PRIVATE subdirectory to the C:\PARTIAL subdirectory. Upon event
  166.     processing, ULP will move the good files from the C:\PRIVATE to the
  167.     C:\PUBLIC subdirectory; all defective archives will be contained in
  168.     C:\PRIVATE.
  169.  
  170.     FWIW, if you want to run with a single directory setup, you must make all
  171.     uploads *public* in PCBSETUP. The subdirectories will look like:
  172.  
  173.         PCBSETUP Designation      Subdirectory      ULP Designation
  174.         --------------------      ------------      ---------------
  175.         Private                   C:\PRIVATE
  176.         Public                    C:\PUBLIC         Source
  177.  
  178.     If a file passes test, it will be moved by PCBoard from the C:\PRIVATE
  179.     subdirectory to the C:\PUBLIC subdirectory. Upon event processing, ULP will
  180.     reprocess only the new files found in the C:\PUBLIC subdirectory; all
  181.     defective archives are still in C:\PRIVATE. Note that the destination
  182.     information in ULPSM is to be left blank.
  183.  
  184. QUESTION:  What I would like to know is if the upload is a duplicate, What file
  185.     is it a duplicate of? I'm certain I have many files with the same CRC...But
  186.     that does not make them duplicates. Since your database is so small
  187.     compaired to ZDCS maybe you don't store that information...
  188.  
  189. ANSWER:  No, I don't store that information. When designing ULP's duplication
  190.     database system, I felt that information wasn't worth worth the database
  191.     space and code required to implement. I'm considering in a future version
  192.     to add a second database format to ULP which includes this ability. It
  193.     would be an option that a sysop may select if they want to sacrifice some
  194.     speed and disk space for that ability. Tentatively, the database size would
  195.     more than double due to that single feature alone.
  196.  
  197.     For a little background, ULP's database system does not rely solely on CRC.
  198.     It uses the combined uniqueness of CRC and file size to determine a file's
  199.     duplication, yeilding accuracy many orders of magnitude greater than a
  200.     simple CRC. The odds of two completely unique files having the same CRC
  201.     *and* file size are astronomical.
  202.  
  203.     To expound, due to the fact a CRC-32 is 32-bits long, it is numerically
  204.     limited to 4 x 10^9 unique combinations. Statistically, most files in
  205.     archives are between a few K and a couple hundred K in size, with a mean
  206.     size of not less than 64K. This yeilds a minimum of 16 additional bits of
  207.     data to "signature" a file, pushing the numerical limit to almost 3 x 10^14
  208.     unique combinations (10,000 times more accurate than CRC-32 alone!). In
  209.     addition, as files become larger, ULP's accuracy actually becomes greater.
  210.  
  211.  
  212. QUESTION:  Is there any way that you can make it process archives with paths
  213.     when they are uploaded when running ULP in SLOW mode?  I hate to see
  214.     archives be posted when there is a possibility of problems with it when a
  215.     few more seconds of testing time won't make much difference at this point.
  216.  
  217. ANSWER:  It's not a timing issue, it's a data accuracy issue. Only ULPTEST has
  218.     the ability to scan an archive directly for the data required (FAST mode),
  219.     and that is the best mode for testing a pathed archive. Remember, files are
  220.     unpacked without regard to paths, so some files may be overwritten, etc.
  221.     during the decompression. These files will be lost in the data collection
  222.     phase of ULP.
  223.  
  224.     Therefore, ULPTEST switches to FAST mode, collects the data and then drops
  225.     out. In the event, ULP will unpack the files without regard to paths, and
  226.     file check them (viruses, etc.) and not repack them. Note that ULP and
  227.     ULPTEST first check the path level, and if some moron simply zipped up an
  228.     archive with a single path, ULP and/or ULPTEST will remove the path from
  229.     the archive by repacking.
  230.  
  231.     This is the best compromise I can come up for handling pathed archives. The
  232.     logistics of handling archives with paths are enormous if unpacked with
  233.     paths intact.
  234.  
  235.  
  236. QUESTION:  Under what conditions can verify.ulp fail and can you think of any
  237.     situation where it would fail, but the upload file itself would pass.
  238.  
  239. ANSWER:  It's fairly bullet-proof...be sure he's reading the information
  240.     correctly? It says whether or not the archive will pass if uploaded, but
  241.     the last message displayed is 'FAILED', since I must fail the VERIFY.ULP
  242.     upload itself (can't give the user credit for uploading that file).
  243.  
  244.  
  245. QUESTION:  ULPTEST would not unpack a file. But if I ran ULP locally it would
  246.     work OK. The funny part was that ULPTEST did not even try to run PKUNIP at
  247.     least there was no indication of that on the screen during the testing
  248.     process.
  249.  
  250. ANSWER:  This sounds very much like a memory problem. Be absolutely sure that
  251.     you have enough free memory and that PCBoard is set to swap on all nodes.
  252.  
  253.  
  254. QUESTION:  ALL of the uploads are failing the "virus, etc" testing!!!
  255.  
  256. ANSWER:  Memory problem...free up a few more K and see what happens. Since it
  257.     worked in the event, and the routines are identical (same source module),
  258.     it must be the operating environment that's the difference.
  259.