home *** CD-ROM | disk | FTP | other *** search
/ Monster Media 1994 #1 / monster.zip / monster / PCBOARD / ULP106.ZIP / Q&A.DOC < prev    next >
Text File  |  1994-01-28  |  19KB  |  370 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.  If the error code is negative (-1, -2 or
  51.     -3), then ULP was unable to start the problem, indicating a memory or
  52.     command line problem.
  53.  
  54.  
  55. QUESTION:  I have a problem with ZDCS and ULP where ULP calls up ZDCS but the
  56.     duplication database doesn't get updated. I am using the latest version of
  57.     both your programs. I can upload the same file 10 times an it passes each
  58.     time.
  59.  
  60. ANSWER:  Your problem is that you are not running in the correct mode of
  61.     operation. Only ULPTEST's SLOW mode updates the database in real time. When
  62.     run in NORMAL mode, ULPTEST only test files, but does not repack or update
  63.     the database. In the event, ULP.EXE will reprocess all new files run in
  64.     NORMAL or FAST modes, repacking them and updating the ZDCS database. This
  65.     is part of the sigificant speed increase in running NORMAL and/or FAST mode
  66.     versus SLOW.
  67.  
  68.  
  69. QUESTION: I want to be able to get the message at the bottom of the description
  70.     that there are Files:X Bytes:Z Newest:J Oldest:Y.  I left the default
  71.     configuration that came with the ULP file but it does not show up.
  72.  
  73. ANSWER:  The information lines are inserted ONLY by ULP.EXE in the event and/or
  74.     by ULPTEST.EXE when in SLOW mode. If you are running ULPTEST in FAST or
  75.     NORMAL modes, the line will be inserted during the event.
  76.  
  77.  
  78. QUESTION:  Files that fail for duplication and/or age are not being renamed.
  79.     What's wrong?
  80.  
  81. ANSWER:  Only ULP.EXE will rename failed files. PCBoard does not permit the
  82.     renaming of uploads during online testing.
  83.  
  84.  
  85. QUESTION:  FILE_ID.DIZ and DESC.SDI files are not being inserted by ULP after
  86.     uploading. Nor is ULPTEST is processing the FILE_ID.DIZ files within zips
  87.     that have subdirectories.  It passes and posts the file, but without
  88.     converting the .DIZ into a description.
  89.  
  90. ANSWER:  ULPTEST FAST mode is unable to insert any FILE_ID.DIZ or DESC.SDI
  91.     files within the upload since it does not unpack the archive. Remember that
  92.     FAST mode is a direct scan of the archive headers, and since the internal
  93.     description file is not physically available, ULPTEST cannot insert it. As
  94.     for the archives with subdirectories, when ULPTEST encounters an archive
  95.     with dissimilar paths, it automatically changes to FAST mode.
  96.  
  97.     However, when reprocessed by ULP.EXE in the event, the internal description
  98.     file will then be inserted.
  99.  
  100.  
  101. QUESTION:  I have intermittent lockups in ULP. Usually the last message on the
  102.     screen is "Swapping in" or "Swapping out".
  103.  
  104. ANSWER:  Swapping can be very tricky, and may be allergic to some systems.
  105.     Swapping ULP and ULPTEST only yields another 100K or so of memory, and if
  106.     you do not absolutely have to have that memory, it would be best to not use
  107.     swapping, for stability and speed concerns. In addition, if you have the
  108.     "internal deletion" switch set to 'N', try 'Y'.
  109.  
  110.  
  111. QUESTION:  I use a 8 meg ram disk and it will tell my users on occasion that
  112.     error work space something. But anyways i have 8 meg in there and it is
  113.     usually a file that is being sent that is around 1400k in size...
  114.  
  115. ANSWER:  The ULP programs now better checks for available disk space prior to
  116.     unpacking, and if a file is too big for the remaining disk space, it will
  117.     be failed for insufficient work space. Note that FAST mode eliminates this
  118.     problem...I would strongly suggest setting the normal mode limit to
  119.     something less than 1/5 of your available work drive space. In your case,
  120.     set the normal limit to around 1200K or so.
  121.  
  122.  
  123. QUESTION:  I get errors of "Can't access process data file", but I can
  124.     initialize it using ULP and ULPSM.
  125.  
  126. ANSWER:  You must include paths for files and subdirectories. The ULP programs
  127.     are very complex, and move around your drives in order to process the files
  128.     and subdirectories configured. If you supply only a filename or a relative
  129.     path, it may or may not work. For all configuration options, include a full
  130.     path, including the drive letter; do not simply enter a filename.
  131.  
  132.  
  133. QUESTION:  It seems that if I am using the 3 dir setup (like originally
  134.     suggested),  my files get processed by ulptest from the private to the
  135.     upload directories just fine. It's ok, just so I know to get rid of my
  136.     ulpfull (fully processed uploads) directory, and set up ulp to process the
  137.     two directory setup.
  138.  
  139. ANSWER:  You probably have the directories crossed. If you want to run the old
  140.     3-directory setup (some do for intermediate, non-ULP processing), you need
  141.     to have it as follows:
  142.  
  143.         PCBSETUP Designation      Subdirectory      ULP Designation
  144.         --------------------      ------------      ---------------
  145.         Private                   C:\PRIVATE
  146.         Public                    C:\PARTIAL        Source
  147.                                   C:\COMPLETE       Destination
  148.  
  149.     If a file passes test, it will be moved by PCBoard from the C:\PRIVATE
  150.     subdirectory to the C:\PARTIAL subdirectory. Upon event processing, ULP
  151.     will move the good files from the C:\PARTIAL to the C:\COMPLETE
  152.     subdirectory. You must have all uploads set to public in PCBSETUP for this
  153.     to work. Failed files will be contained in C:\PRIVATE or C:\PARTIAL,
  154.     depending upon when they failed.
  155.  
  156.     As for the other setup concepts, this is in the docs, but I'll try to
  157.     explain it again...
  158.  
  159.     If you want to run with a 2-directory setup, you must make all uploads
  160.     *private* in PCBSETUP. The subdirectories will look like:
  161.  
  162.         PCBSETUP Designation      Subdirectory      ULP Designation
  163.         --------------------      ------------      ---------------
  164.         Private                   C:\PRIVATE        Source
  165.         Public                    C:\PUBLIC         Destination
  166.  
  167.     Regardless of the results of file testing, uploads will be left by PCBoard
  168.     in the C:\PRIVATE subdirectory to the C:\PARTIAL subdirectory. Upon event
  169.     processing, ULP will move the good files from the C:\PRIVATE to the
  170.     C:\PUBLIC subdirectory; all defective archives will be contained in
  171.     C:\PRIVATE.
  172.  
  173.     FWIW, if you want to run with a single directory setup, you must make all
  174.     uploads *public* in PCBSETUP. The subdirectories will look like:
  175.  
  176.         PCBSETUP Designation      Subdirectory      ULP Designation
  177.         --------------------      ------------      ---------------
  178.         Private                   C:\PRIVATE
  179.         Public                    C:\PUBLIC         Source
  180.  
  181.     If a file passes test, it will be moved by PCBoard from the C:\PRIVATE
  182.     subdirectory to the C:\PUBLIC subdirectory. Upon event processing, ULP will
  183.     reprocess only the new files found in the C:\PUBLIC subdirectory; all
  184.     defective archives are still in C:\PRIVATE. Note that the destination
  185.     information in ULPSM is to be left blank.
  186.  
  187.  
  188. QUESTION:  What I would like to know is if the upload is a duplicate, what file
  189.     is it a duplicate of? I'm certain I have many files with the same CRC...But
  190.     that does not make them duplicates. Since your database is so small
  191.     compaired to ZDCS maybe you don't store that information...
  192.  
  193. ANSWER:  No, I don't store that information. When designing ULP's duplication
  194.     database system, I felt that information wasn't worth worth the database
  195.     space and code required to implement. I'm considering in a future version
  196.     to add a second database format to ULP which includes this ability. It
  197.     would be an option that a sysop may select if they want to sacrifice some
  198.     speed and disk space for that ability. Tentatively, the database size would
  199.     more than double due to that single feature alone.
  200.  
  201.     For a little background, ULP's database system does not rely solely on CRC.
  202.     It uses the combined uniqueness of CRC and file size to determine a file's
  203.     duplication, yeilding accuracy many orders of magnitude greater than a
  204.     simple CRC. The odds of two completely unique files having the same CRC
  205.     *and* file size are astronomically low.
  206.  
  207.     To expound, due to the fact a CRC-32 is 32-bits long, it is numerically
  208.     limited to 4 x 10^9 unique combinations. Statistically, most files in
  209.     archives are between a few K and a couple hundred K in size, with a mean
  210.     size of not less than 64K. The additional resolution pushes the numerical
  211.     limit to around 10 trillion unique combinations (25,000 times more accurate
  212.     than CRC-32 alone!). In addition, as files become larger, ULP's accuracy
  213.     actually becomes greater.
  214.  
  215.  
  216. QUESTION:  Is there any way that you can make it process archives with paths
  217.     when they are uploaded when running ULP in SLOW mode?  I hate to see
  218.     archives be posted when there is a possibility of problems with it when a
  219.     few more seconds of testing time won't make much difference at this point.
  220.  
  221. ANSWER:  It's not a timing issue, it's a data accuracy issue. Only ULPTEST has
  222.     the ability to scan an archive directly for the data required (FAST mode),
  223.     and that is the best mode for testing a pathed archive. Remember, files are
  224.     unpacked without regard to paths, so some files may be overwritten, etc.
  225.     during the decompression. These files will be lost in the data collection
  226.     phase of ULP.
  227.  
  228.     Therefore, ULPTEST switches to FAST mode, collects the data and then drops
  229.     out. In the event, ULP will unpack the files without regard to paths, and
  230.     file check them (viruses, etc.) and not repack them. Note that ULP and
  231.     ULPTEST first check the path level, and if some moron simply zipped up an
  232.     archive with a single path, ULP and/or ULPTEST will remove the path from
  233.     the archive by repacking.
  234.  
  235.     This is the best compromise I can come up for handling pathed archives. The
  236.     logistics of handling archives with paths are enormous if unpacked with
  237.     paths intact.
  238.  
  239.  
  240. QUESTION:  Under what conditions can VERIFY.ULP fail and can you think of any
  241.     situation where it would fail, but the upload file itself would pass.
  242.  
  243. ANSWER:  It's fairly bullet-proof...be sure he's reading the information
  244.     correctly?  It says whether or not the archive will pass if uploaded, but
  245.     the last message displayed is 'FAILED', since I must fail the VERIFY.ULP
  246.     upload itself (can't give the user credit for uploading that file).
  247.  
  248.  
  249. QUESTION:  ULPTEST would not unpack a file. But if I ran ULP locally it would
  250.     work OK. The funny part was that ULPTEST did not even try to run PKUNIP at
  251.     least there was no indication of that on the screen during the testing
  252.     process.
  253.  
  254. ANSWER:  This sounds very much like a memory problem. Be absolutely sure that
  255.     you have enough free memory and that PCBoard is set to swap on all nodes.
  256.  
  257.  
  258. QUESTION:  ALL of the uploads are failing the "virus, etc" testing when online,
  259.     but pass during the event run.
  260.  
  261. ANSWER:  Memory problem...free up a few more K and see what happens. Since it
  262.     worked in the event, and the routines are identical (same source module),
  263.     it must be the operating environment that's the difference.
  264.  
  265.  
  266. QUESTION:  I have the ULP comm port flag set to "Y" but am not getting anything
  267.     out the comm port.  All I see is the "FILENAME.ZIP...passed" message. Is
  268.     this a bug, or something I did wrong?
  269.  
  270. ANSWER:  First, if you are seeing this locally, that is normal. ULPTEST cannot
  271.     update the PCBoard screen buffer during execution.
  272.  
  273.     However, if this is what you see from remote, check to be sure that you
  274.     have the comm port information defined for ULPTEST in some fashion. ULPTEST
  275.     requires the IRQ number, base address and baud rate of the serial port (or
  276.     the FOSSIL port number for /M code) and also the node number. There are
  277.     several means to hand the information to ULPTEST, and they are (in order):
  278.  
  279.     1. It utilizes the information directly passed on the command line.
  280.     2. It will search for the PCBDIR, PCBDAT and PCBDRIVE (optional)
  281.        environment variables to locate the PCBOARD.SYS and PCBOARD.DAT files.
  282.     3. It will look in the current subdirectory where ULPTEST was started from
  283.        for the PCBOARD.SYS and PCBOARD.DAT files.
  284.     4. It checks DSZPORT environment variable for the comm port information.
  285.  
  286.     If it finds a piece of data it needs during the data search, it will use
  287.     that data and look no further for that data element. In this fashion, you
  288.     can specify a DSZPORT to override the PCBOARD.DAT, for example.
  289.  
  290.     I would venture that you have a conflict in your setup, incorrect
  291.     information somewhere or ULPTEST cannot find all of the required data to
  292.     initialize the comm port.
  293.  
  294.  
  295. QUESTION:  I get a SHARE violation on occasion. The last message is "Zip
  296.     comment?" and 9 times out of 10 it does NOT give the Sharing violation
  297.     error.
  298.  
  299. ANSWER:  Other users have experienced similar problems, but in the form of
  300.     network read problems and hangs. From this information, it appears to be a
  301.     file access issue. The only disk accesses between the ZIP commenting and
  302.     the final statistics display locally is the clean up procedure and new file
  303.     size check.
  304.  
  305.     Try setting the "internal file deletion" option to 'Y'. This fixes the
  306.     problem in some cases. It would appear that ULP's internal deletion mode is
  307.     more stable than letting DOS do it with a system() call on some machines.
  308.  
  309.  
  310. QUESTION:  It seems that ULP will fail an upload if the zip has utilized the
  311.     Authenticity Verification option AND there has been a BBS ad attached by
  312.     the receiving bulletin board, namely Rusty & Edie's for example. This
  313.     generates an "Unpacking Error 1" and fails the upload.
  314.  
  315.     Is there something I can do to correct this?  There is actually nothing
  316.     wrong with the upload and this is driving a few of my users nutty.
  317.  
  318. ANSWER:  This is because PKUNZIP returns a non-zero errorlevel for a broken -AV,
  319.     and ULP is configured to recognize 0 as acceptable and non-zero to be
  320.     unacceptable.
  321.  
  322.     Yes, there is something wrong with it: R&E stomped all over the original
  323.     author's -AV, by trying to insert an ad with their *own* -AV. I'd call that
  324.     a hacked archive, if you ask me. If R&E would simply insert an ad file
  325.     without their -AV, it would be fine, but when R&E tried to overwrite the
  326.     -AV stamp with their own upon update, it broke the archive.
  327.  
  328.  
  329. QUESTION:  LZH files have paths. These archives were essentially trashed by
  330.     ULP, since it did convert them to ZIP files, but did not retain the paths.
  331.     I understand the difficulty with pathed archives, but I have no way of
  332.     knowing apriori which archives have paths in them, since unpacking paths is
  333.     the default proceedure with LZH files (unlike zip files which require the
  334.     -d).
  335.  
  336. ANSWER:  Unfortunately, this has been a known limitation of ULP (and probably
  337.     most other upload testers as well).
  338.  
  339.     ULP does not have the ability to directly read an LZH file (ULP can
  340.     internally read only ARC, ARJ, PAK and ZIP archives), since the LZH format
  341.     is not readily defined. The source code is available for LHA, but I haven't
  342.     taken the (extensive) time to trace the code to determine the format. Since
  343.     ULP cannot read the format, it cannot prescan the LZH archives in advance,
  344.     which is how it finds paths and reacts accordingly.
  345.  
  346.     There are a large number of problems associated with processing pathed
  347.     archives, especially when the differing handling schemes employed by the
  348.     various archivers (ARJ, LHA, ZIP, etc.) are considered. It's not a trivial
  349.     task...
  350.  
  351.  
  352. QUESTION:  I would like to second that idea...I for one would love for local
  353.     uploads to be able to insert "Uploaded by: Sysop".
  354.  
  355. ANSWER:  Also, if you are using PCBoard to upload files, it *should* be putting
  356.     in the "Uploaded by:" line. If you are doing them using ULP.EXE (in the
  357.     event, etc.), use a different configuration file, and change the
  358.     information lines to look like:
  359.  
  360.     (Files: @#@ Newest: @NEWEST@ Oldest: @OLDEST@)@CR@Uploaded by: Sysop
  361.  
  362.  
  363. QUESTION:  I experience a hard lockup when swapping during the second
  364.     invokation of ZDCSULP.
  365.  
  366. ANSWER:  Turn off the registration message option in your ZDCS configuration.
  367.     It has been found to produce lockups on a few systems when used in
  368.     conjunction with ULP's swapping code.  Alternately, turn off ULP's swapping
  369.     by setting it to (n)one in ULPSM.
  370.