旼컴컴컴컴컴컴컴컴컴� � � � � � � � � � � � � � 靈캠 � � � � � � � � � � 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? 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.