I would suggest you to look at the Download Directory setting - Options dialog - File Locations. Please try to change it to something simple, like c:\oe\
After downloading please see if there are files in that directory.
Would this help?
Best regards,
Oleg Chernavin
MP Staff
After downloading please see if there are files in that directory.
Would this help?
Best regards,
Oleg Chernavin
MP Staff
Oleg,
Thanks for helping me with this problem.
The download directory is already quite simple: G:\OEP_Misc\.
I think I might have found some things relevant to the problem. But it's rather complicated, so let me know if you need anything clarified....
First, note that all my Projects (including those without this problem) are set to save copies of old files for 31 days, and to datestamp those old file copies using the "filename_7.htm" filename format and the "YYMMDD" datestamp format.
Second, note that most every Project downloads only 1 level of links, and downloads only text files located within or below the starting directory structure. The purpose of these Projects is to track new job opportunities, mostly from employer websites.
Upon examining the OEP Projects today, immediately after starting OEP, it seems that the trouble is coming from Projects for which the Map tab lists many downloaded files, including many datestamped files. In fact, the only files that are *not* datestamped in these problematic Projects are the files that were downloaded as links. The starting files (in effect, the "home pages") are nowhere to be found except in the form of older date-stamped file copies.
If I select one of these Projects (http://www.freespeech.org/html/jobs.shtml), then click the download button, then return to the Map tab, the "home page" is now visible without a datestamp. But I still cannot view this downloaded file -- even if I click on the file name (jobs.shtml) it from within the Map tab.
Next, I will exit & then restart OEP. After restarting OEP, that same "home page" now only exists as a datestamped copy -- and the only downloaded files not datestamped are the files downloaded as links. Much as things were when I first started OEP today.
(By the way, once datestamped, I can click and view the "home page" -- even the very file, judging from the datestamp and the webpage content -- that I downloaded earlier today, before exiting and restarting OEP. That's the very same file that I could not view from within OEP when it was downloaded and listed under its original name: jobs.shtml.)
* Here's some details on the settings used in the Project referred to above.
~ URL(s) to Download:
http://www.freespeech.org/html/jobs.shtml
Additional=AddOriginalURL;CountCRC;SkipIFrames;FinalizeAllFilesOnStop
~ Link Levels: 1
~ Filters include: Text Files; Only from the starting directory and below
~ Skip the following URLs:
http://www.freespeech.org/html/aboutus.shtml
http://www.freespeech.org/html/contact.shtml
http://www.freespeech.org/html/emergencyfund.shtml
http://www.freespeech.org/html/program.shtml
http://www.freespeech.org/html/sitemap.shtml
With all these settings, this Project should download 3 current files (as of 2006-09-08):
jobs.shtml,
dataentry.shtml,
officeadm.shtml.
I hope all this makes sense, and helps you to solve this problem (which has been bothering me for a very long time, and affects several Projects of mine).
Sincerely,
Steve
Thanks for helping me with this problem.
The download directory is already quite simple: G:\OEP_Misc\.
I think I might have found some things relevant to the problem. But it's rather complicated, so let me know if you need anything clarified....
First, note that all my Projects (including those without this problem) are set to save copies of old files for 31 days, and to datestamp those old file copies using the "filename_7.htm" filename format and the "YYMMDD" datestamp format.
Second, note that most every Project downloads only 1 level of links, and downloads only text files located within or below the starting directory structure. The purpose of these Projects is to track new job opportunities, mostly from employer websites.
Upon examining the OEP Projects today, immediately after starting OEP, it seems that the trouble is coming from Projects for which the Map tab lists many downloaded files, including many datestamped files. In fact, the only files that are *not* datestamped in these problematic Projects are the files that were downloaded as links. The starting files (in effect, the "home pages") are nowhere to be found except in the form of older date-stamped file copies.
If I select one of these Projects (http://www.freespeech.org/html/jobs.shtml), then click the download button, then return to the Map tab, the "home page" is now visible without a datestamp. But I still cannot view this downloaded file -- even if I click on the file name (jobs.shtml) it from within the Map tab.
Next, I will exit & then restart OEP. After restarting OEP, that same "home page" now only exists as a datestamped copy -- and the only downloaded files not datestamped are the files downloaded as links. Much as things were when I first started OEP today.
(By the way, once datestamped, I can click and view the "home page" -- even the very file, judging from the datestamp and the webpage content -- that I downloaded earlier today, before exiting and restarting OEP. That's the very same file that I could not view from within OEP when it was downloaded and listed under its original name: jobs.shtml.)
* Here's some details on the settings used in the Project referred to above.
~ URL(s) to Download:
http://www.freespeech.org/html/jobs.shtml
Additional=AddOriginalURL;CountCRC;SkipIFrames;FinalizeAllFilesOnStop
~ Link Levels: 1
~ Filters include: Text Files; Only from the starting directory and below
~ Skip the following URLs:
http://www.freespeech.org/html/aboutus.shtml
http://www.freespeech.org/html/contact.shtml
http://www.freespeech.org/html/emergencyfund.shtml
http://www.freespeech.org/html/program.shtml
http://www.freespeech.org/html/sitemap.shtml
With all these settings, this Project should download 3 current files (as of 2006-09-08):
jobs.shtml,
dataentry.shtml,
officeadm.shtml.
I hope all this makes sense, and helps you to solve this problem (which has been bothering me for a very long time, and affects several Projects of mine).
Sincerely,
Steve
I think, the problem happens because the directory is overloaded - Windows has a limit of files per directory. I would suggest you to clean the directory and enable directory overload protection in the Options dialog - File Locations section.
Oleg.
Oleg.
Hi,
Sorry for the delay in my follow-up. To be honest, the directory size is not an issue. Many of the problematic projects just have around dozen files total, including old file copies. Projects that work fine have directories with many more files. But I did enable the overload protection anyway, since it can't hurt, and it might eventually be useful for me.
Fortunately, I did discover the root of the problem and fixed it (to the best of my knowledge). My WinXP registry settings for file associations and file types had simply been changed. It looks like Dreamweaver (v8) was the culprit ...although some file extensions simply weren't recognized at all, or were identified as simple text file types. So the causes could be multiple.
In any case, for fellow users out there, this is how I fixed it:
1. I listed all the file extensions for all the problematic projects, and then I decided to use IE as the default program for opening files with any of these extensions. And I had to ensure that opening the files -- not editing the files -- would be the default action for each file extension. (These settings would ensure that the files could be browsed in OEP when I clicked an OEP project after downloading such files.)
2. Next, I had to learn the proper settings, or commands, to make all this work. To do this, I accessed the interface for viewing and editing these settings (Control Panel > Folder Options > File Types > Advanced > Edit > Use DDE), and copied every setting & command string for opening files with HTM extensions. (I chose HTM because files with HTM & HTML extensions have always opened as expected in IE & OEP.)
3. I pasted these command strings into the appropriate fields for each of the file extensions that OEP did not seem to recognize. As I recall, all of these extensions were listed. Then I just had to edit the command strings for the "Open" action. Or in some cases, I had to add an "Open" action and make it the default action, adding all the command strings as well.
***
Most instructions for solving such problem recommend this route: File Types > Change [then use the displayed "Open With" window to select a new application for opening such files, then click OK].
But, at least when I used Win98, I found this quick-n-easy route to be deficient. Specifically, if a file association had been changed at some point, this route did not restore all the original settings. And this made a difference w/ some applications I used -- especially those displaying their own list of recent documents upon launching, or those integrated into a genuine suite, etc.
(Granted, a full reversal of a changed file association might require contacting tech support for the chosen application, or consulting support docs to learn the proper settings. Or if an extension is still associated with the chosen application, and those settings have not been altered, then those settings can be copied and pasted to create associations between other extensions and that application.)
Of course, in this case, maybe the quick-n-easy change-file-type route would be just fine.
Whew. Enough said. More than enough.
Sorry for the delay in my follow-up. To be honest, the directory size is not an issue. Many of the problematic projects just have around dozen files total, including old file copies. Projects that work fine have directories with many more files. But I did enable the overload protection anyway, since it can't hurt, and it might eventually be useful for me.
Fortunately, I did discover the root of the problem and fixed it (to the best of my knowledge). My WinXP registry settings for file associations and file types had simply been changed. It looks like Dreamweaver (v8) was the culprit ...although some file extensions simply weren't recognized at all, or were identified as simple text file types. So the causes could be multiple.
In any case, for fellow users out there, this is how I fixed it:
1. I listed all the file extensions for all the problematic projects, and then I decided to use IE as the default program for opening files with any of these extensions. And I had to ensure that opening the files -- not editing the files -- would be the default action for each file extension. (These settings would ensure that the files could be browsed in OEP when I clicked an OEP project after downloading such files.)
2. Next, I had to learn the proper settings, or commands, to make all this work. To do this, I accessed the interface for viewing and editing these settings (Control Panel > Folder Options > File Types > Advanced > Edit > Use DDE), and copied every setting & command string for opening files with HTM extensions. (I chose HTM because files with HTM & HTML extensions have always opened as expected in IE & OEP.)
3. I pasted these command strings into the appropriate fields for each of the file extensions that OEP did not seem to recognize. As I recall, all of these extensions were listed. Then I just had to edit the command strings for the "Open" action. Or in some cases, I had to add an "Open" action and make it the default action, adding all the command strings as well.
***
Most instructions for solving such problem recommend this route: File Types > Change [then use the displayed "Open With" window to select a new application for opening such files, then click OK].
But, at least when I used Win98, I found this quick-n-easy route to be deficient. Specifically, if a file association had been changed at some point, this route did not restore all the original settings. And this made a difference w/ some applications I used -- especially those displaying their own list of recent documents upon launching, or those integrated into a genuine suite, etc.
(Granted, a full reversal of a changed file association might require contacting tech support for the chosen application, or consulting support docs to learn the proper settings. Or if an extension is still associated with the chosen application, and those settings have not been altered, then those settings can be copied and pasted to create associations between other extensions and that application.)
Of course, in this case, maybe the quick-n-easy change-file-type route would be just fine.
Whew. Enough said. More than enough.
Thank you very much for finding the way! This problem is very rare, but still your solution may help other people.
Oleg.
Oleg.
> In any case, for fellow users out there, this is how I fixed it:
Thank you very very much that you described your solution. It also helped me; a long time after you posted it!
Werner (Germany)
Thank you very very much that you described your solution. It also helped me; a long time after you posted it!
Werner (Germany)