From MicroFocusInternationalWiki
Jump to: navigation, search

> my other wikis

features we like about filefinder

summary of filefinder features


  1. I can see when the patch was released, so I can advise my customer.
  2. I can see the location of the file, so I can tell my customer where it is in the patch
  3. I see the module date in addition to the packaged patch date.
  4. I can give a customer a nice short link, that will always be good – as releases are released for example: http://support.novell.com/servlet/filefinder?name=ds.nlm
  5. one click to hit the readme – vs download.novell.com I had to click about 8 times to get to the readme.

Needed improvements to download.novell.com


  1. Addressed Standardized link to use within documentation and TIDs to refer to finding a certain module and have it output a list (similiar to the above screenshot. This is the URL: http://download.novell.com/index.jsp?search=Search&keywords=ds.nlm
    1. auto-output for short URL. One still has to click search and chose sort by date. It'd be nice if it did this automatically as did filefinder. >> This is the URL: http://download.novell.com/index.jsp?search=Search&keywords=ds.nlm&sort_by=date
  2. Addressed I don't see the actual date of the NLM! Nor can I access the readme easily.
  3. Links from TIDs eventually redirect to Patches, which has links that redirect to download.novell.com. TIDs need to be updated to go directly to download.novell.com. (Bugzilla #251745)
    1. As an addendum to above, TIDs usually drop you right to where the family of patches are, this doesn't happen with the redirect so users have a lot more work to find the files that are being referred to in the TIDs.
  4. Addressed Cannot find files contained within patches, search both systems for frequently searched files like ds.nlm, tcp.nlm, nss.nlm with both systems and you'll see the differences quite clearly. This feature is very valuable when looking for updates to files by searching the filenames directly. (This should already be resolved --Travis A)
  5. Won't Fix - Working as designed (WAD) When searching on a specific filename (for example TCPIP.NLM), the "relevancy" percentage is very weird. Either the file is in the patch, or it is not in the patch. The relevancy should therefore be 100% or 0%. Which means that it is useless in that case and should not even be displayed. Which in turns means that, by default, such kind of search should be sorted by date (newest first). (PC) (Bugzilla #251746)
  6. Pending Right now, it is possible to find all the patches for a specific product version *only* by going on the "Basic Search" page. There you can first select the product and then the version and click search. In addition to that, the patches are listed by date (newest first) which is perfect. The problem is that it is impossible to do that on the "Advanced Search" page ! This is counter-intuitive since one would expect the "Advanced Search" to be able to do everything that the "Basic Search" does, plus additional things (Bugzilla #245055). Last but not least, even on the "Basic Search" page, it is really not that intuitive that you can do that. Indeed, at first there is nothing indicating you that you can specificy the product version. It is only after you have selected a specific product that a text appears telling you that you can select a specific version. As a consequence, I think the vast majority of the users are not even aware of that possibility, which really a shame since it is *extremely* useful ! (PC) (This appears to working as intended. The system does not show a version until a product has been selected because it uses the product selection to populate the version numbers. --Travis A)
  7. Addressed What about the beta patches ? Do they appear ? If yes, how and where ? (PC) (Beta patches are called "Field Test Files" and are markes with a red star. --Travis A)
  8. What about the "Suse" patches (NLD, SLES, SLED, NLPS, ...) ? Right now, there is a message indicating that they are not accessible from there. Is that temporary ? I certainly hope so !!! (PC) For now the SUSE patches can be found under the "linux patches" tab. Soon they will be integrated on the Patches tab.
  9. I compose a newsletter that is distributed by NTS (and even some sales folks) to our clients world-wide. I used to be able to include a table that listed the "New This Week" patches (see attached). Now that the FileFinder has been replaced by PatchBuilder, this information is no longer available. I can see that someone has raised similar issues in the DLfeedback Wiki but there was no mention of the loss of the "What's New" (both "This Week" and "This Month") and the fact that our clients no longer have an easy way of quickly browsing through the latest patches. While the change from the FileFinder to PatchBuilder makes it more difficult for me to compose the newsletter, the real problem is that it makes it MUCH more difficult for our clients to instantly check for newly released patches that may apply to their environments. Our clients have limited resources, which is one reason why the newsletter has been so popular. By putting information - such as a table or link - at their fingertips, they can save what little time they have. The "new releases" list on the main download page is, frankly, a poor replacement, as it requires several clicks to find information that used to be available in one click. I just wanted to add my concerns about how the recent changes will affect our clients; add me to the list of names of those who want the old FileFinder back. (Brent P.) (From http://support.novell.com/patches.html you can click "View new patches in the last 7 days" and "View new patches in the last 30 days". --Travis A)
  10. Addressed When searching for a filename is is not possible to use wildcards (i.e. tcpip.*). This was very helpful if you don't know the exact filename. (Reinhard D.) (Bugzilla #251531)
  11. When searching for updates for nw65sp6, i've noticed that lots of updates have a tag which isn't selectable thru the menu. (Alex W.)
  12. Addressed Amazing doing a search for Example for apache2.nlm. It doesn 't give you anything back for apache2.nlm 's coming with different SP 's nor versions. Instead got no results back, even choose the product/technology apache.(Markus E.) (The site will now search, and show, the contents of compressed patch files. So, you should be able to search for specific NLMs and have relevant returns. --Travis A)
  13. When looking at patches on download.novell.com, you have to login to view the associated TID. With FileFinder you had the choice of reading the TID or going directly to the download page. With download.novell.com you have to 'proceed to download' in order to download (read) the associated readme file (formerly known as the TID). Readme added to bottom of patch download page.
  14. WIP Files aren't available thru FTP access, which is an requirement at several customers. (Alex W.) (Bugzilla #251759)
    1. This was very useful as a means of being able to locally mirror FTP server (for internal only access) in order to save bandwidth (Simon F.)
  15. Mostly Addressed Meaningless patch names: Since the move to download.novell.com, there are more and more patches with meningless names like novpatchxxxx.zip. Furthermore, the number of the patch doesn't even match the TID number of the readme. While I'm sure it is ultimately the person who releases the patch that is responsible for the name, I have the strong suspicion that the new site encourages people to use those meanlingless names rather than forcing them to provide a real name. Please don't provide default names for patches but force everyone to provide a real name.
  16. WIP Novell should provide automated notifications to customers who downloaded updates that were later superceded or removed/pulled (example: initial release of ConsoleOne 1.3.6g), or updates whose status changed (such as from 'field test' to 'public'). (Bugzilla #251786)
  17. WNF Useful readme files are missing within the patch archives, instead we're getting a html file containing a link back to the file we've just downloaded. A patch archive has to have a meaningful name and must contain a text-formatted readme. Will Not Fix; most engineers will continue to give intuitive names to their patches but engineers who require a unique name will have the option to use a generic name.
  18. Files that were always available for download on filefinder should remain downloadable on download.novell.com. I've had enough of regularly hitting files that are suddenly no longer searchable or downloadable. The latest such example is N65NSS5B.EXE. This file was available for download for about 6 months on filefinder. Now, Novell has suddenly decided that this file is no longer public. You can't find it in download.novell.com unless you have the exact link which is http://download.novell.com/Download?buildid=Pn6DDe96i-U~ , and even with that link, the site tells you that you have no rights to download the file. You now have to go through all the pain of having to call novell to get this file. Is this really progress?
  19. WIP Minimum Patch List grouped by product(Bugzilla # 245048).
  20. Addressed Auto-sort by date. I know it uses its fancy algorithm, but I like newest to oldest output by default. It is a pain to have to click sort by date each time. (Bugzilla # 265625) Search results are always sorted by date EXCEPT if you insert text in the Keyword field, it which case the sort results are sorted by relevancy by default. However if you switch to "Sort by Date" your preference will be saved and it will be used next time you do a search.
  21. WIP Patch Metadata is badly messed up when it comes to exact product versions. Some patches are only tagged to the base product version while others are only tagged to a particular support pack. Examples are all the Groupwise 7 SP2 patches. These patches are all tagged to Groupwise 7.02, e.g. Groupwise 7 SP2. This means that SP2 for Groupwise 7 should only be applied to installations that already have SP2 installed. This is of course absurd. Another example are recent NetWare 6.5 patches after SP6. Some of these patches are only tagged for NetWare 6.5 (no SP) while others are only tagged for NetWare 6.5 SP6. This means that neither search for just NetWare 6.5 nor searching for NetWare 6.5 SP6 gives you a complete list of patches. The worst thing about this is that customers who don't know about the existence of certain patches will never get a decent list of patches that really exist for their installation. The only way for a cutomer to be sure he doesn't miss a patch is knowing that the patch exists before even looking for it on download.novell.com. My suggestion to fix this problem is to drop the idea to tag the patches by support pack level. The patches should only be tagged by product version number excluding the support pack level. Including the support pack level just leads to errors are the current mess clearly shows. It's amazing how this tagging by product version which always worked perfectly on filefinder seems to be so hard to fix on download.novell.com.
  22. WIP Bug 277072 The patch readme should contain the list of files contained in it. The following is an example of a readme that just repeats the name of the ZIP file rather than showing what is in it. http://download.novell.com/Download?buildid=7wHTtVGVG7o~

Bugzilla numbers and follow-ups to this section were submitted by Travis Adamson. You can submit additional concerns and feedback directly to me at: patch-downloads@novell.com

FAQ of download.novell.com


Brainshare & Direct Feedback

If you are going to visit Brainshare this year, be sure to visit Novell's web site program table to provide your personal feedback. The programs tables will be located in the main lobby near the south entrance as in years past.

You may also provide your feedback directly by e-mailing patch-downloads@novell.com

Your stories about download.novell.com not working

A couple of days, some Novell employee removed the section about the vote to bring filefinder back. It's obvious that Novell doesn't really want to admit that people preferred the old site. Rather than bringing back the simple vote section, I think it's better to add a section showing on how download.novell.com didn't do the job for you.
For me, the last drop is download.novell.com not working once again today (Thursday 15 March 2007). Since the switch to download.novell.com, there have already been problems with the site numerous times. There were times that the Novell login was not working, and today, it is simply all files having vanished from the site. Nothing left, nix, nada. Can you imagine the frutration of me being at a customer site not being able to download a much needed patch? It is already hard enough defending Novell products, but if you can't even properly support these products because of a non working web site, then it becomes really hard. The switch from filefinder to download.novell.com has been really one of the worst things to come out of Novell lately. I really have the impression that the people who did the switch had absolutely no proper planning for the switch, no talking with customers and Novell engineers that have to daily deal with patches (I have talked to many Novell people who are equally frustrated with download.novell.com as I am). It really looks to me like the people in charge of the switch are a bunch of blind people stumbling along, and it is the customers that have to take them by the hand and point out to them each single stupid thing they do. It seems to me that all web development for the switch only happened after the switch and only based on very vocal feedback from the customers. The people in charge simply have no idea of what functionality customers need and the idea of asking anyone concerned beforehand is completely alien to them.

--Marcel 02:30, 15 March 2007 (MDT)

Marcel, we've communicated a bit and I "think" your concerns (I know you and I share a lot of the same concerns.) are being addressed. If not, email patch-downloads@novell.com or me (you have my email address. Thomas E.

internal wiki