I want to report some bugs with long filenames, image detection and the "Restore" function:
1.) Bugs with long filenames
I wanted to see how OE deals with long filenames. Please follow these steps to reproduce the bug:
- Create a directory "test" in c: (c:\test)
- Place a file with a long filename in this folder:
000000000011111111112222222222333333333344444444445555555555666666666677777777778888888888999999999900000000001111111111222222222233333333334444444444555555555566666666667777777777888888888899999999990000000000.jpg
- Create a new project with "Text" and "Images" enabled (Load from any site)
- URLs: file://c:\test- Download the project
- The JPG file is saved with the original name.
- Click on Map
- Move the mouse over the long filename; you will only see a part of the filename:
0000000000111111111122222222223333333333444444444455555555556666666666777777777
But why?
- Click on default.htm
- The internal browser shows the original long filename
- Click on the link to the JPG file
- The browser can`t open the file, because:
- The link to the filename is:
file:///C:/Test/00000000001111111111222222222233333333334444444444555555555566666666667777777777888888888899999999990EC5A8D7D1
That would be ok. But in fact, the file isn`t truncated on the disk! Its filename in the download directory (c:\download) is still:
000000000011111111112222222222333333333344444444445555555555666666666677777777778888888888999999999900000000001111111111222222222233333333334444444444555555555566666666667777777777888888888899999999990000000000.jpg
***BUG***
Exporting the project with Joliet format enabled doesn`t help:
The export process creates a directory with 2 files in it:
00000000001111111111222222222233333333334444444444555~1.jpg
default.htm
But the browser can`t find the file, because the default.htm has a wrong link in it:
<HTML><HEAD><TITLE>Directory of C:\Test\</TITLE></HEAD><BODY><PRE>
<a href="c_3a/test/00000000001111111111222222222233333333334444444444555~1">000000000011111111112222222222333333333344444444445555555555666666666677777777778888888888999999999900000000001111111111222222222233333333334444444444555555555566666666667777777777888888888899999999990000000000.jpg</a>
</PRE></BODY></HTML>
Where does "c_3a/test/" come from? It shouldn`t be there!
***BUG***
The truncated filename lost its extension ".jpg" in the link. But after the export the filename on the disk is:
00000000001111111111222222222233333333334444444444555~1.jpg
That`s a second reason why the browser can`t find the file.
***BUG***
2.) Bugs with image files without an extension
- Instead of the JPG file with the long filename, place 5 files without an extension in c:\test
Test_bmp
Test_gif
Test_jpg
Test_png
Test_tif
(I converted a JPG file into different formats in IrfanView)
- Download the files
- Export them with "Use standard extensions for files with known file types" enabled
- The result:
Test_bmp
Test_gif.gif
Test_jpg.jpg
Test_png
Test_tif
(BTW: the "c_3a/test/" bug still exists here)
OEP doesn`t recognise bmp, png, and tif files. But I can see also "image/png" in Descr.WD3. I guess this is a:
***BUG***
3.) Bugs in the "Restore" function
Start OEP without any webdown.dat (empty "Projects" tree; only "Default" folder)
- Create 12 new projects
- Backup them (Click on the "Default" folder and then "Backup")
- Delete the "Default" folder with all projects
- Restore the 12 previously saved projects:
OEP hangs while restoring the Backup!
(It happens with folders with more than 10 projects;
BTW: OEP starts without problems if you are copying the webdown.dat from the Backup into the Projects directory.)
***BUG***
Another bug in the Restore function:
Nearly the same as above:
- Create a few new projects under the "Default" folder (less than 10)
- Backup the pro
1.) Bugs with long filenames
I wanted to see how OE deals with long filenames. Please follow these steps to reproduce the bug:
- Create a directory "test" in c: (c:\test)
- Place a file with a long filename in this folder:
000000000011111111112222222222333333333344444444445555555555666666666677777777778888888888999999999900000000001111111111222222222233333333334444444444555555555566666666667777777777888888888899999999990000000000.jpg
- Create a new project with "Text" and "Images" enabled (Load from any site)
- URLs: file://c:\test- Download the project
- The JPG file is saved with the original name.
- Click on Map
- Move the mouse over the long filename; you will only see a part of the filename:
0000000000111111111122222222223333333333444444444455555555556666666666777777777
But why?
- Click on default.htm
- The internal browser shows the original long filename
- Click on the link to the JPG file
- The browser can`t open the file, because:
- The link to the filename is:
file:///C:/Test/00000000001111111111222222222233333333334444444444555555555566666666667777777777888888888899999999990EC5A8D7D1
That would be ok. But in fact, the file isn`t truncated on the disk! Its filename in the download directory (c:\download) is still:
000000000011111111112222222222333333333344444444445555555555666666666677777777778888888888999999999900000000001111111111222222222233333333334444444444555555555566666666667777777777888888888899999999990000000000.jpg
***BUG***
Exporting the project with Joliet format enabled doesn`t help:
The export process creates a directory with 2 files in it:
00000000001111111111222222222233333333334444444444555~1.jpg
default.htm
But the browser can`t find the file, because the default.htm has a wrong link in it:
<HTML><HEAD><TITLE>Directory of C:\Test\</TITLE></HEAD><BODY><PRE>
<a href="c_3a/test/00000000001111111111222222222233333333334444444444555~1">000000000011111111112222222222333333333344444444445555555555666666666677777777778888888888999999999900000000001111111111222222222233333333334444444444555555555566666666667777777777888888888899999999990000000000.jpg</a>
</PRE></BODY></HTML>
Where does "c_3a/test/" come from? It shouldn`t be there!
***BUG***
The truncated filename lost its extension ".jpg" in the link. But after the export the filename on the disk is:
00000000001111111111222222222233333333334444444444555~1.jpg
That`s a second reason why the browser can`t find the file.
***BUG***
2.) Bugs with image files without an extension
- Instead of the JPG file with the long filename, place 5 files without an extension in c:\test
Test_bmp
Test_gif
Test_jpg
Test_png
Test_tif
(I converted a JPG file into different formats in IrfanView)
- Download the files
- Export them with "Use standard extensions for files with known file types" enabled
- The result:
Test_bmp
Test_gif.gif
Test_jpg.jpg
Test_png
Test_tif
(BTW: the "c_3a/test/" bug still exists here)
OEP doesn`t recognise bmp, png, and tif files. But I can see also "image/png" in Descr.WD3. I guess this is a:
***BUG***
3.) Bugs in the "Restore" function
Start OEP without any webdown.dat (empty "Projects" tree; only "Default" folder)
- Create 12 new projects
- Backup them (Click on the "Default" folder and then "Backup")
- Delete the "Default" folder with all projects
- Restore the 12 previously saved projects:
OEP hangs while restoring the Backup!
(It happens with folders with more than 10 projects;
BTW: OEP starts without problems if you are copying the webdown.dat from the Backup into the Projects directory.)
***BUG***
Another bug in the Restore function:
Nearly the same as above:
- Create a few new projects under the "Default" folder (less than 10)
- Backup the pro
Just to report about the progress - I just fixed the long filenames and links issues. I also improved export of PNG files. I will work on the backup issues soon as well.
Best regards,
Oleg Chernavin
MP Staff
Best regards,
Oleg Chernavin
MP Staff
OK. I fixed all of the backup/restore issues. If you need the updated version now, just let me know.
Oleg.
Oleg.
Thank you very much for fixing the mentioned bugs!
I found a new OEP version and tested it.
Some notes:
1.)
>> - Move the mouse over the long filename; you will only see a part of the filename:
>>
>> 0000000000111111111122222222223333333333444444444455555555556666666666777777777
>>
>> But why?
OK, this limitation is still there.
(Do you have plans to change this in future?)
2.)
OEP now detects the PNG files correctly.
(The BMP and TIF file formats aren`t detected. But I think that this isn`t too bad, because these image formats aren`t spread widely.)
3.)
There is still something wrong with the export (contents.htm):
Some lines from contents.htm after the export to d:\export\ :
-----
<ContentsBody>
<li><a href="c:/test/default.htm">file://c:\test\</a><p>
</ContentsBody>
<ContentsBody>
<li><a href="c:/test/default.htm">URL: file://c:\test\</a><p>
</ContentsBody>
</ul></font></body></html>
<ContentsFile />
-----
This isn`t OK.
This would work:
-----
<ContentsBody>
<li><a href="local files/test/default.htm">file://c:\test\</a><p>
</ContentsBody>
<ContentsBody>
<li><a href="local files/test/default.htm">URL: file://c:\test\</a><p>
</ContentsBody>
</ul></font></body></html>
<ContentsFile />
-----
4.)
A small issue:
- When you click on the MAP tab, the Download button isn`t greyed out.
- Click on the Download button.
- OEP tries to download from:
http://localfiles/test/
5.)
Another Bug (not mentioned above):
- Try do download a project with "DeleteAfterParsing=..."
- Stop the download
- Delete the "DeleteAfterParsing=..." line
- Start the download
OEP doesn`t recognize the new setting!
The "DeleteAfterParsing=..." line is still in OEP`s memory.
A workaround:
Close OEP and start the download.
I get the same effect with "Proxy=..."
But this bug doesn`t exist with all additional lines.
Maybe you should check them all (you can do it better than I ;-)?
Thank you!
I found a new OEP version and tested it.
Some notes:
1.)
>> - Move the mouse over the long filename; you will only see a part of the filename:
>>
>> 0000000000111111111122222222223333333333444444444455555555556666666666777777777
>>
>> But why?
OK, this limitation is still there.
(Do you have plans to change this in future?)
2.)
OEP now detects the PNG files correctly.
(The BMP and TIF file formats aren`t detected. But I think that this isn`t too bad, because these image formats aren`t spread widely.)
3.)
There is still something wrong with the export (contents.htm):
Some lines from contents.htm after the export to d:\export\ :
-----
<ContentsBody>
<li><a href="c:/test/default.htm">file://c:\test\</a><p>
</ContentsBody>
<ContentsBody>
<li><a href="c:/test/default.htm">URL: file://c:\test\</a><p>
</ContentsBody>
</ul></font></body></html>
<ContentsFile />
-----
This isn`t OK.
This would work:
-----
<ContentsBody>
<li><a href="local files/test/default.htm">file://c:\test\</a><p>
</ContentsBody>
<ContentsBody>
<li><a href="local files/test/default.htm">URL: file://c:\test\</a><p>
</ContentsBody>
</ul></font></body></html>
<ContentsFile />
-----
4.)
A small issue:
- When you click on the MAP tab, the Download button isn`t greyed out.
- Click on the Download button.
- OEP tries to download from:
http://localfiles/test/
5.)
Another Bug (not mentioned above):
- Try do download a project with "DeleteAfterParsing=..."
- Stop the download
- Delete the "DeleteAfterParsing=..." line
- Start the download
OEP doesn`t recognize the new setting!
The "DeleteAfterParsing=..." line is still in OEP`s memory.
A workaround:
Close OEP and start the download.
I get the same effect with "Proxy=..."
But this bug doesn`t exist with all additional lines.
Maybe you should check them all (you can do it better than I ;-)?
Thank you!
1.) I think, it is only a display problem. Do you see the correct filename when you scroll the map to the right? Maybe it is a remains from the previous download (with the old version)?
2.) Yes, BMP and TIF files are not standard for Web graphics.
3.) Fixed.
4.) This is normal, because the Download button in Map allows you to redownload any particular file.
5.) Fixed. Thank you!
Do you need the updated version right now?
Oleg.
2.) Yes, BMP and TIF files are not standard for Web graphics.
3.) Fixed.
4.) This is normal, because the Download button in Map allows you to redownload any particular file.
5.) Fixed. Thank you!
Do you need the updated version right now?
Oleg.
> 1.) I think, it is only a display problem. Do you see the correct filename when you scroll the map to the right?
Yes, I can see the correct filename in the Map tree. (But the filename is truncated in the yellow "tooltip" area).
I have the same problem when I move the mouse over a long project name.
> Maybe it is a remains from the previous download (with the old version)?
No.
2.) Yes, BMP and TIF files are not standard for Web graphics.
Of course, that would be horrible. ;-)
4.) This is normal, because the Download button in Map allows you to redownload any particular file.
Yes, I didn`t saw that "default.htm" is selected everytime when I click on this specific Map tab, and I was irritated by the fact that OE tried to download from http://localfiles/test/ ("http://" and "local files" without any space between "local" and "files")
OK, the files aren`t stored in the directory "file@c" (or someting like this, so that OE could know where the files were downloaded from). But I really don`t need this feature! Simply forget it. ;-)
> Do you need the updated version right now?
You don`t have to upload a new beta after every little bug-fixing. But anyway:
Thank you!
Yes, I can see the correct filename in the Map tree. (But the filename is truncated in the yellow "tooltip" area).
I have the same problem when I move the mouse over a long project name.
> Maybe it is a remains from the previous download (with the old version)?
No.
2.) Yes, BMP and TIF files are not standard for Web graphics.
Of course, that would be horrible. ;-)
4.) This is normal, because the Download button in Map allows you to redownload any particular file.
Yes, I didn`t saw that "default.htm" is selected everytime when I click on this specific Map tab, and I was irritated by the fact that OE tried to download from http://localfiles/test/ ("http://" and "local files" without any space between "local" and "files")
OK, the files aren`t stored in the directory "file@c" (or someting like this, so that OE could know where the files were downloaded from). But I really don`t need this feature! Simply forget it. ;-)
> Do you need the updated version right now?
You don`t have to upload a new beta after every little bug-fixing. But anyway:
Thank you!
The latest update is here:
http://www.metaproducts.com/download/betas/oep1831.zip
The short hint problems are because of the standard Windows control limitations. I will try to workaround that.
Oleg.
http://www.metaproducts.com/download/betas/oep1831.zip
The short hint problems are because of the standard Windows control limitations. I will try to workaround that.
Oleg.
> The latest update is here:
>
> http://www.metaproducts.com/download/betas/oep1831.zip
Thanks. This works. :-)
> The short hint problems are because of the standard Windows control limitations. I will try to workaround that.
Thank you!
>
> http://www.metaproducts.com/download/betas/oep1831.zip
Thanks. This works. :-)
> The short hint problems are because of the standard Windows control limitations. I will try to workaround that.
Thank you!
Great!
Oleg.
Oleg.