home
***
CD-ROM
|
disk
|
FTP
|
other
***
search
/
Monster Media 1994 #1
/
monster.zip
/
monster
/
PCBOARD
/
ULP106.ZIP
/
Q&A.DOC
< prev
next >
Wrap
Text File
|
1994-01-28
|
19KB
|
370 lines
┌───────────────────┐
│ │ ║
│ ╥ ╥ ╥ │ ║ UpLoadProcessor
│ ║ ║ ║ ╓──╖ │ ║
│ ║ ║ ║ ║ ║ │ ║
│ ╙───╜ ╨ ║──╜ │ ║ Answers to Common Questions
│ ╨ │ ║
└───────────────────┘ ║
════════════════════╝
The following are some frequently-asked questions extracted from my support
conference, which may answer questions or problems you may have with ULP:
QUESTION: A file was uploaded to my board, and was failed for duplication and
renamed to .DUP. But, it wasn't really a dupe, but just a really similar
update, so I renamed it to .ZIP, and changed the entry to .Zip in the uldir
file, as well.
Unfortunately, the next time I ran ULP, it processed it as a brand new file
again and renamed it to zip again. Evidently, files that are rejected by
ULP.EXE do not get put into the process.dat file, and will be processed
over and over again ad infinitem?
ANSWER: ULP entered the filename xxxxxxxx.DUP in the process data file. As far
as ULP is concerned, when you renamed it to .ZIP, it became a new file to
be processed. This is by design.
You should have done one of two things. Run ULP.EXE in override mode (-O
command line parameter), without renaming the .DUP file, which would
process all new files and reprocess all failed files without regard to age
or duplication. This is good for a large number of .AGE and .DUP files that
you want to process at once, not to mention the files are converted,
recompressed, commented, BBS ads removed, etc.
Alternatively, after you renamed the .DUP to .ZIP in the upload area, you
could have reinitialized the process data file to correctly enter the
renamed filename. This is probably simpler when renaming one or two files,
but does not yield the benefit of conversion, recompression, et al.
QUESTION: I installed the new beta and uploaded (locally) FILENAME.ZIP and
again, it failed with "failed file checking [exit code 2]".
ANSWER: The information in the brackets is the errorlevel that was returned to
ULPTEST (and ULP as well) by the external process. You need to look in the
documentation for the file checker that failed, and see what error code 2
is. The reason I've added that information to the logs is to allow sysops
to better debug their setups. If the error code is negative (-1, -2 or
-3), then ULP was unable to start the problem, indicating a memory or
command line problem.
QUESTION: I have a problem with ZDCS and ULP where ULP calls up ZDCS but the
duplication database doesn't get updated. I am using the latest version of
both your programs. I can upload the same file 10 times an it passes each
time.
ANSWER: Your problem is that you are not running in the correct mode of
operation. Only ULPTEST's SLOW mode updates the database in real time. When
run in NORMAL mode, ULPTEST only test files, but does not repack or update
the database. In the event, ULP.EXE will reprocess all new files run in
NORMAL or FAST modes, repacking them and updating the ZDCS database. This
is part of the sigificant speed increase in running NORMAL and/or FAST mode
versus SLOW.
QUESTION: I want to be able to get the message at the bottom of the description
that there are Files:X Bytes:Z Newest:J Oldest:Y. I left the default
configuration that came with the ULP file but it does not show up.
ANSWER: The information lines are inserted ONLY by ULP.EXE in the event and/or
by ULPTEST.EXE when in SLOW mode. If you are running ULPTEST in FAST or
NORMAL modes, the line will be inserted during the event.
QUESTION: Files that fail for duplication and/or age are not being renamed.
What's wrong?
ANSWER: Only ULP.EXE will rename failed files. PCBoard does not permit the
renaming of uploads during online testing.
QUESTION: FILE_ID.DIZ and DESC.SDI files are not being inserted by ULP after
uploading. Nor is ULPTEST is processing the FILE_ID.DIZ files within zips
that have subdirectories. It passes and posts the file, but without
converting the .DIZ into a description.
ANSWER: ULPTEST FAST mode is unable to insert any FILE_ID.DIZ or DESC.SDI
files within the upload since it does not unpack the archive. Remember that
FAST mode is a direct scan of the archive headers, and since the internal
description file is not physically available, ULPTEST cannot insert it. As
for the archives with subdirectories, when ULPTEST encounters an archive
with dissimilar paths, it automatically changes to FAST mode.
However, when reprocessed by ULP.EXE in the event, the internal description
file will then be inserted.
QUESTION: I have intermittent lockups in ULP. Usually the last message on the
screen is "Swapping in" or "Swapping out".
ANSWER: Swapping can be very tricky, and may be allergic to some systems.
Swapping ULP and ULPTEST only yields another 100K or so of memory, and if
you do not absolutely have to have that memory, it would be best to not use
swapping, for stability and speed concerns. In addition, if you have the
"internal deletion" switch set to 'N', try 'Y'.
QUESTION: I use a 8 meg ram disk and it will tell my users on occasion that
error work space something. But anyways i have 8 meg in there and it is
usually a file that is being sent that is around 1400k in size...
ANSWER: The ULP programs now better checks for available disk space prior to
unpacking, and if a file is too big for the remaining disk space, it will
be failed for insufficient work space. Note that FAST mode eliminates this
problem...I would strongly suggest setting the normal mode limit to
something less than 1/5 of your available work drive space. In your case,
set the normal limit to around 1200K or so.
QUESTION: I get errors of "Can't access process data file", but I can
initialize it using ULP and ULPSM.
ANSWER: You must include paths for files and subdirectories. The ULP programs
are very complex, and move around your drives in order to process the files
and subdirectories configured. If you supply only a filename or a relative
path, it may or may not work. For all configuration options, include a full
path, including the drive letter; do not simply enter a filename.
QUESTION: It seems that if I am using the 3 dir setup (like originally
suggested), my files get processed by ulptest from the private to the
upload directories just fine. It's ok, just so I know to get rid of my
ulpfull (fully processed uploads) directory, and set up ulp to process the
two directory setup.
ANSWER: You probably have the directories crossed. If you want to run the old
3-directory setup (some do for intermediate, non-ULP processing), you need
to have it as follows:
PCBSETUP Designation Subdirectory ULP Designation
-------------------- ------------ ---------------
Private C:\PRIVATE
Public C:\PARTIAL Source
C:\COMPLETE Destination
If a file passes test, it will be moved by PCBoard from the C:\PRIVATE
subdirectory to the C:\PARTIAL subdirectory. Upon event processing, ULP
will move the good files from the C:\PARTIAL to the C:\COMPLETE
subdirectory. You must have all uploads set to public in PCBSETUP for this
to work. Failed files will be contained in C:\PRIVATE or C:\PARTIAL,
depending upon when they failed.
As for the other setup concepts, this is in the docs, but I'll try to
explain it again...
If you want to run with a 2-directory setup, you must make all uploads
*private* in PCBSETUP. The subdirectories will look like:
PCBSETUP Designation Subdirectory ULP Designation
-------------------- ------------ ---------------
Private C:\PRIVATE Source
Public C:\PUBLIC Destination
Regardless of the results of file testing, uploads will be left by PCBoard
in the C:\PRIVATE subdirectory to the C:\PARTIAL subdirectory. Upon event
processing, ULP will move the good files from the C:\PRIVATE to the
C:\PUBLIC subdirectory; all defective archives will be contained in
C:\PRIVATE.
FWIW, if you want to run with a single directory setup, you must make all
uploads *public* in PCBSETUP. The subdirectories will look like:
PCBSETUP Designation Subdirectory ULP Designation
-------------------- ------------ ---------------
Private C:\PRIVATE
Public C:\PUBLIC Source
If a file passes test, it will be moved by PCBoard from the C:\PRIVATE
subdirectory to the C:\PUBLIC subdirectory. Upon event processing, ULP will
reprocess only the new files found in the C:\PUBLIC subdirectory; all
defective archives are still in C:\PRIVATE. Note that the destination
information in ULPSM is to be left blank.
QUESTION: What I would like to know is if the upload is a duplicate, what file
is it a duplicate of? I'm certain I have many files with the same CRC...But
that does not make them duplicates. Since your database is so small
compaired to ZDCS maybe you don't store that information...
ANSWER: No, I don't store that information. When designing ULP's duplication
database system, I felt that information wasn't worth worth the database
space and code required to implement. I'm considering in a future version
to add a second database format to ULP which includes this ability. It
would be an option that a sysop may select if they want to sacrifice some
speed and disk space for that ability. Tentatively, the database size would
more than double due to that single feature alone.
For a little background, ULP's database system does not rely solely on CRC.
It uses the combined uniqueness of CRC and file size to determine a file's
duplication, yeilding accuracy many orders of magnitude greater than a
simple CRC. The odds of two completely unique files having the same CRC
*and* file size are astronomically low.
To expound, due to the fact a CRC-32 is 32-bits long, it is numerically
limited to 4 x 10^9 unique combinations. Statistically, most files in
archives are between a few K and a couple hundred K in size, with a mean
size of not less than 64K. The additional resolution pushes the numerical
limit to around 10 trillion unique combinations (25,000 times more accurate
than CRC-32 alone!). In addition, as files become larger, ULP's accuracy
actually becomes greater.
QUESTION: Is there any way that you can make it process archives with paths
when they are uploaded when running ULP in SLOW mode? I hate to see
archives be posted when there is a possibility of problems with it when a
few more seconds of testing time won't make much difference at this point.
ANSWER: It's not a timing issue, it's a data accuracy issue. Only ULPTEST has
the ability to scan an archive directly for the data required (FAST mode),
and that is the best mode for testing a pathed archive. Remember, files are
unpacked without regard to paths, so some files may be overwritten, etc.
during the decompression. These files will be lost in the data collection
phase of ULP.
Therefore, ULPTEST switches to FAST mode, collects the data and then drops
out. In the event, ULP will unpack the files without regard to paths, and
file check them (viruses, etc.) and not repack them. Note that ULP and
ULPTEST first check the path level, and if some moron simply zipped up an
archive with a single path, ULP and/or ULPTEST will remove the path from
the archive by repacking.
This is the best compromise I can come up for handling pathed archives. The
logistics of handling archives with paths are enormous if unpacked with
paths intact.
QUESTION: Under what conditions can VERIFY.ULP fail and can you think of any
situation where it would fail, but the upload file itself would pass.
ANSWER: It's fairly bullet-proof...be sure he's reading the information
correctly? It says whether or not the archive will pass if uploaded, but
the last message displayed is 'FAILED', since I must fail the VERIFY.ULP
upload itself (can't give the user credit for uploading that file).
QUESTION: ULPTEST would not unpack a file. But if I ran ULP locally it would
work OK. The funny part was that ULPTEST did not even try to run PKUNIP at
least there was no indication of that on the screen during the testing
process.
ANSWER: This sounds very much like a memory problem. Be absolutely sure that
you have enough free memory and that PCBoard is set to swap on all nodes.
QUESTION: ALL of the uploads are failing the "virus, etc" testing when online,
but pass during the event run.
ANSWER: Memory problem...free up a few more K and see what happens. Since it
worked in the event, and the routines are identical (same source module),
it must be the operating environment that's the difference.
QUESTION: I have the ULP comm port flag set to "Y" but am not getting anything
out the comm port. All I see is the "FILENAME.ZIP...passed" message. Is
this a bug, or something I did wrong?
ANSWER: First, if you are seeing this locally, that is normal. ULPTEST cannot
update the PCBoard screen buffer during execution.
However, if this is what you see from remote, check to be sure that you
have the comm port information defined for ULPTEST in some fashion. ULPTEST
requires the IRQ number, base address and baud rate of the serial port (or
the FOSSIL port number for /M code) and also the node number. There are
several means to hand the information to ULPTEST, and they are (in order):
1. It utilizes the information directly passed on the command line.
2. It will search for the PCBDIR, PCBDAT and PCBDRIVE (optional)
environment variables to locate the PCBOARD.SYS and PCBOARD.DAT files.
3. It will look in the current subdirectory where ULPTEST was started from
for the PCBOARD.SYS and PCBOARD.DAT files.
4. It checks DSZPORT environment variable for the comm port information.
If it finds a piece of data it needs during the data search, it will use
that data and look no further for that data element. In this fashion, you
can specify a DSZPORT to override the PCBOARD.DAT, for example.
I would venture that you have a conflict in your setup, incorrect
information somewhere or ULPTEST cannot find all of the required data to
initialize the comm port.
QUESTION: I get a SHARE violation on occasion. The last message is "Zip
comment?" and 9 times out of 10 it does NOT give the Sharing violation
error.
ANSWER: Other users have experienced similar problems, but in the form of
network read problems and hangs. From this information, it appears to be a
file access issue. The only disk accesses between the ZIP commenting and
the final statistics display locally is the clean up procedure and new file
size check.
Try setting the "internal file deletion" option to 'Y'. This fixes the
problem in some cases. It would appear that ULP's internal deletion mode is
more stable than letting DOS do it with a system() call on some machines.
QUESTION: It seems that ULP will fail an upload if the zip has utilized the
Authenticity Verification option AND there has been a BBS ad attached by
the receiving bulletin board, namely Rusty & Edie's for example. This
generates an "Unpacking Error 1" and fails the upload.
Is there something I can do to correct this? There is actually nothing
wrong with the upload and this is driving a few of my users nutty.
ANSWER: This is because PKUNZIP returns a non-zero errorlevel for a broken -AV,
and ULP is configured to recognize 0 as acceptable and non-zero to be
unacceptable.
Yes, there is something wrong with it: R&E stomped all over the original
author's -AV, by trying to insert an ad with their *own* -AV. I'd call that
a hacked archive, if you ask me. If R&E would simply insert an ad file
without their -AV, it would be fine, but when R&E tried to overwrite the
-AV stamp with their own upon update, it broke the archive.
QUESTION: LZH files have paths. These archives were essentially trashed by
ULP, since it did convert them to ZIP files, but did not retain the paths.
I understand the difficulty with pathed archives, but I have no way of
knowing apriori which archives have paths in them, since unpacking paths is
the default proceedure with LZH files (unlike zip files which require the
-d).
ANSWER: Unfortunately, this has been a known limitation of ULP (and probably
most other upload testers as well).
ULP does not have the ability to directly read an LZH file (ULP can
internally read only ARC, ARJ, PAK and ZIP archives), since the LZH format
is not readily defined. The source code is available for LHA, but I haven't
taken the (extensive) time to trace the code to determine the format. Since
ULP cannot read the format, it cannot prescan the LZH archives in advance,
which is how it finds paths and reacts accordingly.
There are a large number of problems associated with processing pathed
archives, especially when the differing handling schemes employed by the
various archivers (ARJ, LHA, ZIP, etc.) are considered. It's not a trivial
task...
QUESTION: I would like to second that idea...I for one would love for local
uploads to be able to insert "Uploaded by: Sysop".
ANSWER: Also, if you are using PCBoard to upload files, it *should* be putting
in the "Uploaded by:" line. If you are doing them using ULP.EXE (in the
event, etc.), use a different configuration file, and change the
information lines to look like:
(Files: @#@ Newest: @NEWEST@ Oldest: @OLDEST@)@CR@Uploaded by: Sysop
QUESTION: I experience a hard lockup when swapping during the second
invokation of ZDCSULP.
ANSWER: Turn off the registration message option in your ZDCS configuration.
It has been found to produce lockups on a few systems when used in
conjunction with ULP's swapping code. Alternately, turn off ULP's swapping
by setting it to (n)one in ULPSM.