home *** CD-ROM | disk | FTP | other *** search
-
- ┌───────────────────┐
- │ │ ║
- │ ╥ ╥ ╥ │ ║
- │ ║ ║ ║ ╓──╖ │ ║
- │ ║ ║ ║ ║ ║ │ ║ UpLoadProcessor Frequently Asked Questions
- │ ╙───╜ ╨ ║──╜ │ ║
- │ ╨ │ ║
- └───────────────────┘ ║
- ════════════════════╝
-
-
- /*===========================================================================*/
-
- >> Am having problems with ULP reporting the following...
- >>
- >> Node Work subdirectory not empty/available...decremented
- >>
- >> I have checked the work directory, which is K:\ULP\WORK, and found
- >> nothing in it. It says it decremented...to what? What should I look
- >> for.
-
- It indicates a node collision in attempting to create node-specific files on
- startup. When this happens, it logs the problem and adjusts the node number
- until it can run safely without stomping on the other files.
-
- This is caused by one of two problems: running ULP in two different windows
- and/or workstations with the same node number or trash in the work
- subdirectory. Usually it's the latter, but it can't hurt to check your system
- for accidental node duplication. Try removing your work subdirectory and let
- ULP recreate it, and see if that solves your problem.
-
- /*===========================================================================*/
-
- >> I'm getting some trouble with InfoZIP, too. Sometimes it gives me an error
- >> errorlevel 50! I can't find the problem for that, but it happens only a
- >> few times. [OS/2 versions]
-
- Try turning off the "run in window flag" for the ZIP archiver. I've found that
- InfoZIP's UNZIP sometimes gives an errorlevel 50 due to the stdout I/O
- redirection thread.
-
- /*===========================================================================*/
-
- >> I'm running PCB under Dos. So when someone uploads a program programmed
- >> for Win95 [or OS/2, Unix] with long file names then I can still use the
- >> regular pkzip right?
-
- Yes, but not exactly. Under DOS, PKUNZIP will spit out a warning and skip
- unpacking a file that won't fit under DOS filename constraints. ULP will stop
- processing the file at that point to prevent destruction of the archive.
-
- Any person writing Windows 95 software should know this and take appropriate
- steps to keep his filenames within the FAT filename limits, otherwise he risks
- trashing of his archives by the thousands of BBSs out there that are running
- under DOS.
-
- Note that if you run the OS/2 version of ULP under OS/2 on HPFS drives, this
- will not be an issue as the long filenames will be processed properly and
- retained without error.
-
- /*===========================================================================*/
-
- >> I finally got around to setting ULP up and have 2.10 sucessfully
- >> working except for one point. Below is a log entry...
- >>
- >> ULP 2.10 Session: 12-29-95 20:23:45 ├──────────────────────────┤ OS: DOS v
- >> *** WARNING : Node work subdirectory not empty/available...decremented
- >> Upload Processing Mode
- >> Matched to upload directory set 1
- >> Slow mode enabled...running on node -1
- >> [ ... ]
- >> The work directory setup in ULPSM is K:\ULP\ULPWORK and the data directory
- >> K:\ULP\ULPDATA. There are NO files in these directories, when I look at them
- >> I have tried several things including erasing the subdirectories and having
- >> ULP create them, which it does handily. But I still get this error on every
- >> file processed.
-
- The only way I can think of that can cause this to occur on every file is by
- feeding a node number of 0 to ULP, either on the command line or via the drop
- file (PCBOARD.SYS or DOOR.SYS). Node 0 is not a valid node number, either to
- ULP or PCBoard (at least not according to their manual).
-
- /*===========================================================================*/
-
- >>-> Every time I see a duplication report the same question pops immediately
- >>-> in my mind. "What was the name of the other file involved?"
-
- >> I've wondered the same thing. But, I'd guess that the database has CRC val
- >> as opposed to file names. I could be wrong, but why store the name. Especi
- >> if the file has be renamed. I'd imagine that it would be caught too based
- >> the CRC. Make sense? <g>
-
- ULP stores only mathematical data in the database that represents the file; it
- does not know either the name of the file or the archive from which it came.
- To do that would require a minimum tripling of the database size and the
- incremental speed penalty of manipulating that extra data.
-
- However, ZDCS *does* have the ability you desire and ULP has hooks built-in for
- ZDCS.
-
- /*===========================================================================*/
-
- >> Today I installed the new ULP v2.10. It's working fine for me except
- >> for one thing. When a user uploads a RAR-packed archive which is
- >> password-protected, RAR (and thus ULP) waits for the password to be
- >> entered and waits till sysop-intervention is made. This could be very
- >> annoying for those who check the new uploads during a nightly event.
-
- It's not a bug in ULP...the problem is with RAR. There is no way to disable or
- override the password question; RAR's author should not make the assumption
- that someone is around to answer RAR's questions.
-
- For example, PKUNZIP exits with an error if it encounters a password protected
- archive without specifying the -S command switch.
-
- That being said, I've found a workaround: add "-p." to your RAR unpacking
- command line. This will feed a fake password to RAR (a period), forcing it to
- try and unpack it, ultimately failing. At least it won't stop and ask a dumb
- question (be sure you have "-y" on the command line as well).
-
- /*===========================================================================*/
-
- >> The other thing is there an errorlevel returned when the dup database
- >> validation fails? I can only tell that it returns a 0 from the log
- >> file. The reason I ask is that I do a compile as an event and I am
- >> unable to tell if I need to delete the .IDX file if there is a problem.
- >> Would it be easier just to delete the .IDX file before running the even
- >> in any case?
-
- Not recommended. If the validation fails, the database is most likely mangled.
- I've yet to see an instance of a defective index, so if you simply bypass the
- validation failure and recompile anyway, well...GIGO.
-
- >> About the duplicate database. If I delete the index after it fails it
- >> will recompile without any problems.
-
- Yes, it will...all the validation data is in the index, so ULPSM just blindly
- compiles the raw database when the index is missing, incorporating and assuming
- valid any crap within. If ULPSM reports the database is corrupt, there's only
- a 1 in 4 billion chance it's wrong.
-
- /*===========================================================================*/
-
- >> Is there a reason the hispeed and lospeed templates were dropped from
- >> the distribution file? I didn't notice it until I saw they were version
- >> 2.0.
-
- They are not (and never have been) in the distribution archive, at least not in
- the usual sense. They are automatically created when ULP is first installed by
- running ULPSM with a new configuration filename.
-
- If you want to change the version number in the templates, just do it the old-
- fashioned way: use a text editor. Or use the @VERSION@ macro instead which
- will always reflect the current version in the templates.
-
- /*===========================================================================*/
-
- >> On this [help] screen, under desqview, with no mouse
- >> [ ...screen snipped... ]
- >> How do I access the buttons at the bottom, eg Index ?
-
- Alt-I. Also, the "Prev" button is accessed through the Alt-F1 key combination
- and "Quit" is the same as pressing ESC.
-
- /*===========================================================================*/
-
- >> Also, the JPEG detection seems to be muffed up. I have 1 JPG file that came
- >> through the LORD-FDN (the only JPG I've had come in anywhere) and ULP says
- >> it's an "Unknown" format. Yet the JPEG viewer I have reads/displays it fine
-
- You probably have the image parameters for JPEG set to 0x0x0. That disables
- JPEG detection (same with GIF). At least one of the image values must be
- non-zero in order for it to be identified and processed. Try 0x0x1 and see
- what happens (that setting will pass any JPEG it encounters).
-
- /*===========================================================================*/
-
- >> ZIPs with -AV get re-compressed during processing. Also, ARJ self-
- >> extractors with security envelopes get re-compressed as well.
-
- Note that for a -AV protected archive to be considered valid, *all* files
- within the archive must have an -AV stamp. If even one file is missing the
- stamp, the archive will not be considered protected and will be repacked to
- eradicate evidence of the stamp. This is done to prevent tampering where a
- file or two is added or replaced and still considered protected by the author's
- original -AV. Generally, if a BBS ad is added to a -AV protected archive, it
- will be repacked by ULP since the ad is not stamped.
-
- As for ARJ self-extracting archives, ULP can't detect security envelopes in ARJ
- SFX files. There's no documented or simple means of finding the global header
- short of searching byte by byte. I may implement it in a future version if it
- can be done without impacting the archive scanning speed.
-