home *** CD-ROM | disk | FTP | other *** search
/ Carsten's PPE Collection / Carstens_PPE_Collection_2007.zip / U / ULP_108.ZIP / Q&A.DOC < prev    next >
Text File  |  1994-06-08  |  19KB  |  360 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 #]".
  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 program, 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 (before the new 15.1)
  82.     does not permit the 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 use a 8 meg ram disk and it will tell my users on occasion that
  102.     error work space something. But anyways i have 8 meg in there and it is
  103.     usually a file that is being sent that is around 1400k in size...
  104.  
  105. ANSWER:  The ULP programs now better checks for available disk space prior to
  106.     unpacking, and if a file is too big for the remaining disk space, it will
  107.     be failed for insufficient work space. Note that FAST mode eliminates this
  108.     problem...I would strongly suggest setting the normal mode limit to
  109.     something less than 1/5 of your available work drive space. In your case,
  110.     set the normal limit to around 1200K or so.
  111.  
  112.     Note, however, that sometimes you might have a failure for insufficient
  113.     work space on a relatively small archive. The reason for this is nested
  114.     archives; once a file has been started on a drive, it stays there. When a
  115.     nested archive is detected, it starts unpacking it on the same drive, so
  116.     the amount of disk space required for that file effectively almost doubled.
  117.     With another layer of nested archives, it doubles again, ad infinitum.
  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.  
  185. QUESTION:  What I would like to know is if the upload is a duplicate, what file
  186.     is it a duplicate of? I'm certain I have many files with the same CRC...But
  187.     that does not make them duplicates. Since your database is so small
  188.     compaired to ZDCS maybe you don't store that information...
  189.  
  190. ANSWER:  No, ULP doesn't store that information. When designing ULP's internal
  191.     duplication database system, I felt that information wasn't worth worth the
  192.     database space and code required to implement. I'm considering in a future
  193.     version to add a second database format to ULP which includes this ability.
  194.     It would be an option that a sysop may select if they want to sacrifice
  195.     some speed and disk space for that ability. Tentatively, the database size
  196.     would more than double due to that single feature alone.
  197.  
  198.     For a little background, ULP's database system does not rely solely on CRC.
  199.     It uses the combined uniqueness of CRC and file size to determine a file's
  200.     duplication, yeilding accuracy many orders of magnitude greater than a
  201.     simple CRC. The odds of two completely unique files having the same CRC
  202.     *and* file size are astronomically low.
  203.  
  204.     To expound, due to the fact a CRC-32 is 32-bits long, it is numerically
  205.     limited to 4 x 10^9 unique combinations. Statistically, most files in
  206.     archives are between a few K and a couple hundred K in size, with a mean
  207.     size of not less than 64K. The additional resolution pushes the numerical
  208.     limit to around 10 trillion unique combinations (25,000 times more accurate
  209.     than CRC-32 alone!). In addition, as files become larger, ULP's accuracy
  210.     actually becomes greater.
  211.  
  212.  
  213. QUESTION:  Is there any way that you can make it process archives with paths
  214.     when they are uploaded when running ULP in SLOW mode?  I hate to see
  215.     archives be posted when there is a possibility of problems with it when a
  216.     few more seconds of testing time won't make much difference at this point.
  217.  
  218. ANSWER:  It's not a timing issue, it's a data accuracy issue. Only ULPTEST has
  219.     the ability to scan an archive directly for the data required (FAST mode),
  220.     and that is the best mode for testing a pathed archive. Remember, files are
  221.     unpacked without regard to paths, so some files may be overwritten, etc.
  222.     during the decompression. These files will be lost in the data collection
  223.     phase of ULP.
  224.  
  225.     Therefore, ULPTEST switches to FAST mode, collects the data and then drops
  226.     out. In the event, ULP will unpack the files without regard to paths, and
  227.     file check them (viruses, etc.) and not repack them. Note that ULP and
  228.     ULPTEST first check the path level, and if some moron simply zipped up an
  229.     archive with a single path, ULP and/or ULPTEST will remove the path from
  230.     the archive by repacking.
  231.  
  232.     This is the best compromise I can come up for handling pathed archives. The
  233.     logistics of handling archives with paths are enormous if unpacked with
  234.     paths intact.
  235.  
  236.  
  237. QUESTION:  Under what conditions can VERIFY.ULP fail and can you think of any
  238.     situation where it would fail, but the upload file itself would pass.
  239.  
  240. ANSWER:  It's fairly bullet-proof...be sure he's reading the information
  241.     correctly?  It says whether or not the archive will pass if uploaded, but
  242.     the last message displayed is 'FAILED', since I must fail the VERIFY.ULP
  243.     upload itself (can't give the user credit for uploading that file).
  244.  
  245.  
  246. QUESTION:  ULPTEST would not unpack a file. But if I ran ULP locally it would
  247.     work OK. The funny part was that ULPTEST did not even try to run PKUNZIP at
  248.     least there was no indication of that on the screen during the testing
  249.     process.
  250.  
  251. ANSWER:  This sounds very much like a memory problem. Be absolutely sure that
  252.     you have enough free memory and that PCBoard is set to swap on all nodes.
  253.  
  254.  
  255. QUESTION:  ALL of the uploads are failing the "virus, etc" testing when online,
  256.     but pass during the event run.
  257.  
  258. ANSWER:  Memory problem...free up a few more K and see what happens. Since it
  259.     worked in the event, and the routines are identical (same source module),
  260.     it must be the operating environment that's the difference.  SCAN has
  261.     become a massive memory hog, almost to the point of being unusable.  Try
  262.     another scanner such as F-PROT or Thunderbyte.
  263.  
  264.  
  265. QUESTION:  I have the ULP comm port flag set to "Y" but am not getting anything
  266.     out the comm port.  All I see is the "FILENAME.ZIP...passed" message. Is
  267.     this a bug, or something I did wrong?
  268.  
  269. ANSWER:  First, if you are seeing this locally, that is normal. ULPTEST cannot
  270.     update the PCBoard screen buffer during execution.
  271.  
  272.     However, if this is what you see from remote, check to be sure that you
  273.     have the comm port information defined for ULPTEST in some fashion. ULPTEST
  274.     requires the IRQ number, base address and baud rate of the serial port (or
  275.     the FOSSIL port number for /M code) and also the node number. There are
  276.     several means to hand the information to ULPTEST, and they are (in order):
  277.  
  278.     1. It utilizes the information directly passed on the command line.
  279.     2. It will search for the PCBDIR, PCBDAT and PCBDRIVE (optional)
  280.        environment variables to locate the PCBOARD.SYS and PCBOARD.DAT files.
  281.     3. It will look in the current subdirectory where ULPTEST was started from
  282.        for the PCBOARD.SYS and PCBOARD.DAT files.
  283.     4. It checks DSZPORT environment variable for the comm port information.
  284.  
  285.     If it finds a piece of data it needs during the data search, it will use
  286.     that data and look no further for that data element. In this fashion, you
  287.     can specify a DSZPORT to override the PCBOARD.DAT, for example.
  288.  
  289.     I would venture that you have a conflict in your setup, incorrect
  290.     information somewhere or ULPTEST cannot find all of the required data to
  291.     initialize the comm port.
  292.  
  293.  
  294. QUESTION:  I get a SHARE violation on occasion. The last message is "Zip
  295.     comment?" and 9 times out of 10 it does NOT give the Sharing violation
  296.     error.
  297.  
  298. ANSWER:  Other users have experienced similar problems, but in the form of
  299.     network read problems and hangs. From this information, it appears to be a
  300.     file access issue. The only disk accesses between the ZIP commenting and
  301.     the final statistics display locally is the clean up procedure and new file
  302.     size check.
  303.  
  304.     Try setting the "internal file deletion" option to 'Y'. This fixes the
  305.     problem in some cases. It would appear that ULP's internal deletion mode is
  306.     more stable than letting DOS do it with a system() call on some machines.
  307.  
  308.  
  309. QUESTION:  It seems that ULP will fail an upload if the zip has utilized the
  310.     Authenticity Verification option AND there has been a BBS ad attached by
  311.     the receiving bulletin board, namely Rusty & Edie's for example. This
  312.     generates an "Unpacking Error 1" and fails the upload.
  313.  
  314.     Is there something I can do to correct this?  There is actually nothing
  315.     wrong with the upload and this is driving a few of my users nutty.
  316.  
  317. ANSWER:  This is because PKUNZIP returns a non-zero errorlevel for a broken -AV,
  318.     and ULP is configured to recognize 0 as acceptable and non-zero to be
  319.     unacceptable.
  320.  
  321.     Yes, there is something wrong with it: R&E stomped all over the original
  322.     author's -AV, by trying to insert an ad with their *own* -AV. I'd call that
  323.     a hacked archive, if you ask me. If R&E would simply insert an ad file
  324.     without their -AV, it would be fine, but when R&E tried to overwrite the
  325.     -AV stamp with their own upon update, it broke the archive.
  326.  
  327.  
  328. QUESTION:  LZH files have paths. These archives were essentially trashed by
  329.     ULP, since it did convert them to ZIP files, but did not retain the paths.
  330.     I understand the difficulty with pathed archives, but I have no way of
  331.     knowing apriori which archives have paths in them, since unpacking paths is
  332.     the default proceedure with LZH files (unlike zip files which require the
  333.     -d).
  334.  
  335. ANSWER:  Unfortunately, this has been a known limitation of ULP (and probably
  336.     most other upload testers as well).
  337.  
  338.     ULP does not have the ability to directly read an LZH file (ULP can
  339.     internally read only ARC, ARJ, PAK and ZIP archives), since the LZH format
  340.     is not readily defined. The source code is available for LHA, but I haven't
  341.     taken the (extensive) time to trace the code to determine the format. Since
  342.     ULP cannot read the format, it cannot prescan the LZH archives in advance,
  343.     which is how it finds paths and reacts accordingly.
  344.  
  345.     There are a large number of problems associated with processing pathed
  346.     archives, especially when the differing handling schemes employed by the
  347.     various archivers (ARJ, LHA, ZIP, etc.) are considered. It's not a trivial
  348.     task...
  349.  
  350.  
  351. QUESTION:  I would like to second that idea...I for one would love for local
  352.     uploads to be able to insert "Uploaded by: Sysop".
  353.  
  354. ANSWER:  Also, if you are using PCBoard to upload files, it *should* be putting
  355.     in the "Uploaded by:" line. If you are doing them using ULP.EXE (in the
  356.     event, etc.), use a different configuration file, and change the
  357.     information lines to look like:
  358.  
  359.     (Files: @#@ Newest: @NEWEST@ Oldest: @OLDEST@)@CR@Uploaded by: Sysop
  360.