ie bookmarks not imported properly

VERIFIED DUPLICATE of bug 53152

Status

()

Core
RDF
P3
normal
VERIFIED DUPLICATE of bug 53152
18 years ago
16 years ago

People

(Reporter: Jilles van Gurp, Assigned: dougt)

Tracking

Trunk
x86
Other
Points:
---

Firefox Tracking Flags

(Not tracked)

Details

Attachments

(1 attachment)

(Reporter)

Description

18 years ago
The imnported IE bookmarks folder does not contain all my bookmarks. I have 
experienced this problem with several versions of mozilla (M17, a nightly build 
from 5 August). I noticed that it is always the same bookmarks that are 
missing. I can't see that these bookmarks are in any way special or different 
(they're just files)
(Reporter)

Comment 1

18 years ago
Created attachment 12515 [details]
these are my favorites, the demedia/music/frankblack folder is empty after importing

Comment 2

18 years ago
*** Bug 47457 has been marked as a duplicate of this bug. ***

Comment 3

18 years ago
setting bug status to New.
Status: UNCONFIRMED → NEW
Ever confirmed: true

Comment 4

18 years ago
I think that I have tracked down the source of the I.E. favorites not showing 
up properly. I've noticed that any favorite containing the string "..." cause 
problems. If such a favorite is in a folder, all favorites which should appear 
after it do not appear.

On my computer I had the following bookmarks in one of my IE folders:
Aberdeen
AccessMicro.Com ...more products, faster service, on time delivery!
CompUSA
Dell

notice the "..." in the second bookmark. All bookmarks after this one did not 
show not show up in the "Imported IE favorites" in mozilla. This behavior was 
consistent with any bookmark containing "..." placed in any directory.

You will notice that the first bookmark in the "demedia/music/frankblack" 
folder (in the favorites attached to this bug) is titled "... and on the 8th 
day God created Frank Black !". Again, notice the "..."

Comment 5

18 years ago
I want to comment on Daniels comment. I'm experiencing the same problem, but I
don't think it's caused by dots in bookmark-names.

Description:
Currently using build 2000090408 on Win95 (Dutch) with IE 4 installed, but bug
also surfaces on other builds. My IE-bookmarks are in c:\windows\favorieten\ (20
items and 7 folders). In my "imported IE bookmarks" bookmarks-folder, only 7
show up. The ones that don't show up do NOT have dots in their names.

I think that the ones showing up are from an old version of my IE bookmarks
(meaning that I've added bookmarks since then, but they didn't show up). Are
bookmarks re-read everytime Mozilla starts up/everytime the folder is selected?
How is that done?

Comment 6

18 years ago
I'm having similar problem using the 2000-09-11-06-M18 nightly build, and 
earlier: If any bookmark has a file name which includes the string "..", the 
bookmark list is cut short. And since the file names are on the form <bookmark 
name>.url it's enough if the name of the bookmark *ends* with a ".".

However, this problem does not appear to be limited to imported bookmarks 
alone. I get a similar phenomenon if I do the following:

* Create a new folder, let's call it C:\break
* Create three files in it, let's call them a.txt, b..txt, and c.txt
* Enter file://C:/break as URL.

Mozilla lists the directory as containing only one file: a.txt (Actually, this 
probably depends on the order in Mozilla sees the file names. If I create 
b..txt first, I don't see any files at all.) If I change the name of b..txt to 
b.txt and reload the "page", I see all three.

(This probably isn't as surprising as it may first seem. If you look at the 
Mozilla bookmarks.html file, you'll see that the imported IE bookmarks is 
simply an URL pointing to the Windows Favorites folder.)

Comment 7

18 years ago
sounds like a core RDF issue. reassigning to waterson, cc rjc.
I would concentrate on the most recent steps just outlined.
Assignee: slamm → waterson
Component: Bookmarks → RDF
QA Contact: claudius → tever

Comment 8

18 years ago
(Just a guess) This smells like a problem with nsIFile.  dougt, know of any 
problems regarding ".." handling?
Assignee: waterson → dougt

Comment 9

18 years ago
Ok, another addendum. All IE bookmark-files (*.url) after one titled "A brief
MUI user guide." (notice the dot) got read, but not imported/displayed. I know
they are read, because there is one exception to the rule: a bookmark titled
"AnandTech". That bookmark is the only one following the one ending with the dot
that does not have any non-alphanumeric characters in its title, but I'm not
certain that that is causing it to show up. (Are you with me? ;)

Later, I removed dots at the end of other IE-bookmarks and more imported ones
started to appear. So I'm quite certain that the ".." triggers the improper
import. I hope this helps.

P.S. For clarity: my previous comment was incorrect, because there WERE
bookmarks with ".." in it. I had forgotten about the ".url" extension.

Comment 10

18 years ago
I think that I may have found the root of the problem in
mozilla/xpcom/io/nsLocalFileWin.cpp (Actually the code also exists in similar
forms in nsLocalFileUnix.cpp and nsLocalFileOS2.cpp). The following line of code
appears in the nsLocalFile::AppendRelativePath method:

// Cannot start with a / or have .. or have / anywhere
if (!node || (*node == '/') || (strstr(node, "..") != nsnull) ||
   (strchr(node, '/') != nsnull))

This will discard any string which contains a ".." anywhere in the string.
However, this causes problems with files that legitimately contain ".."
somewhere in the filename.

It seems to me that the purpose of this code is to prevent from appending a path
which would lead up the directory tree instead of down. The following are cases
which would violate this behavior:

1) node begins with "../"
2) node ends with "/.."
3) node contains "/../" anywhere within the string
4) node begins with "/"
5) node equals ".."

I cannot think of any other cases which would cause problems. If there are no
other possibilities, then you can catch cases 1-4 with a strchr(node,'/') and
then use a strcmp(node,"..") to catch the final case. This would result in the
following line of code:

if(strchr(node,'/')!=nsnull || strcmp(node,"..")!=0)

I am also wondering if we should really be looking for '\\' instead of '/' since
that is the character used as the path separator on windows. Is there some other
reason to look for the '/'?
(Assignee)

Comment 11

18 years ago
Daniel, does this fix the problem??

I think that reducing the current logic to what you suggest will break most 
relative path appendage.

Comment 12

18 years ago
My IE favs do not contain any ".." strings, but they are truncated in the 
middle. That is to say that the first 3 items show up, and the last two, but 
nothing in-between.
(Assignee)

Comment 13

18 years ago
This is a dup of 53152.  If we fix the .. problems, ie bookmarks should work.


*** This bug has been marked as a duplicate of 53152 ***
Status: NEW → RESOLVED
Last Resolved: 18 years ago
Resolution: --- → DUPLICATE

Comment 14

18 years ago
I believe, VERIFIED Dupe
Status: RESOLVED → VERIFIED

Comment 15

18 years ago
*** Bug 55146 has been marked as a duplicate of this bug. ***

Comment 16

18 years ago
*** Bug 55701 has been marked as a duplicate of this bug. ***
*** Bug 68633 has been marked as a duplicate of this bug. ***

Comment 18

17 years ago
I've found that by removing the single trailing "." in the Favorites shortcuts'
descriptions "Enlight Corp." and "FirstSource Int.", they, and all subsequent
Favorites in their respective lists, appear in the "Imported IE Favorites"
folder where they didn't before; while Favorites with a "." in the midst of the
description's string as per "MSN.com" and "XML.com" had never posed any problem.

Comment 19

16 years ago
Mass removing self from CC list.
You need to log in before you can comment on or make changes to this bug.