187.27 KB, application/octet-stream
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)
Created attachment 12515 [details] these are my favorites, the demedia/music/frankblack folder is empty after importing
*** Bug 47457 has been marked as a duplicate of this bug. ***
setting bug status to New.
Status: UNCONFIRMED → NEW
Ever confirmed: true
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 "..."
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?
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.)
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
(Just a guess) This smells like a problem with nsIFile. dougt, know of any problems regarding ".." handling?
Assignee: waterson → dougt
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.
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 '/'?
Daniel, does this fix the problem?? I think that reducing the current logic to what you suggest will break most relative path appendage.
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.
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
I believe, VERIFIED Dupe
Status: RESOLVED → VERIFIED
*** Bug 55146 has been marked as a duplicate of this bug. ***
*** Bug 55701 has been marked as a duplicate of this bug. ***
*** Bug 68633 has been marked as a duplicate of this bug. ***
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.
Mass removing self from CC list.
You need to log in before you can comment on or make changes to this bug.