#535 Hyperlink (File Chooser) creates relative path

_FreeMind_0.9.0
open-accepted
nobody
None
4
2008-03-29
2007-12-17
Andrew
No

When you choose Insert, Hyperlink (File Chooser), FreeMind adds extra characters to the path (e.g. "../../C:/WINDOWS/winnt.bmp"). This creates a quasi-relative path.

When you move .mm files to a different folder, the hyperlink won't work if the destination folder is at a different level than the source folder.

The drag-and-drop method does not add these extra characters.

FreeMind 0.9.0 b15
JRE 1.5.0_12
Windows XP SP2

Discussion

  • Andrew

    Andrew - 2007-12-17

    Example: Hyperlink (File Chooser)

     
  • Andrew

    Andrew - 2007-12-17

    Updated file w/ images

     
  • Andrew

    Andrew - 2007-12-17

    Logged In: YES
    user_id=1735169
    Originator: YES

    This issue also affects Insert, Image (File Chooser or Link). Quasi relative path is used (e.g. "../../C:/WINDOWS/Web/Wallpaper/Windows XP.jpg").

    If you Edit Long Node, switch to HTML Code View and remove the "../../" characters, the image no longer shows up in the map.

    Not sure if this is the same issue or if a new bug needs to be created.
    File Added: Hyperlink Bug.mm

     
  • Eric L.

    Eric L. - 2008-03-29
    • priority: 5 --> 4
    • status: open --> open-accepted
     
  • Eric L.

    Eric L. - 2008-03-29

    Logged In: YES
    user_id=318488
    Originator: NO

    Different things don't sound right:
    1. the result shouldn't be different depending on how you add the link.
    2. the quasi-relative path is definitely a sick one.
    3. under Linux, drag&drop adds a node with an absolute path as text instead of adding an hyperlink.

    Be just aware that you can instruct FreeMind to use absolute paths under menu Tools -> Preferences... -> Appearance -> Hyperlink types. For this reason, I set down the priority and we'll attack the hyperlink code after release of 0.9.0.

    Eric

     
  • ScottyDM

    ScottyDM - 2010-01-28

    The title of this bug report is a bit misleading. The problem is as andrewk8 stated: A relative path is more quasi-relative than true relative. FM is now adding a bunch of "../" strings to back down to the root of the disk drive, then adding path back in to get to the folder where the file is located. The way I have my projects structured this is unnecessary and unwanted.

    Example:

    Using Ctrl-Shift-K FM might create a link like -- "../../../CreativeWriting/stories/instinct_and_intellect/version_0-4-4/ms__ch01_the_restaurant.odt"

    Rather, it should have created the link -- "version_0-4-4/ms__ch01_the_restaurant.odt" -- because the MM file is in the folder -- "/CreativeWriting/stories/instinct_and_intellect/"

    Note that in this example "CreativeWriting" is a folder on another machine set up as a share and mapped to drive "Y" on the test machine. Unlike andrewk8 I'm not seeing the drive letter included in the verbose path.

    This bug did not exist on 0.9.0 rc3 or rc4, but I now see it on rc6.

    I'm running Windows 2000 Pro on both host and remote machines in a Windows Domain environment.

    The work around is to select the FM node with the verbose hyperlink path and type Ctrl-K. This gets the little hyperlink edit popup and the hyperlink may be manually simplified.

    It'd be awesome if this were fixed before 0.9.0 production release.

    Thanks!

     
  • Daniel Polansky

    Daniel Polansky - 2010-02-06

    I confirm the bug in FreeMind 0.9.0 RC6 and in FreeMind 0.8.1. A precondition for reproducing the bux is that the setting Tools > Preferences... > Appearance > Hyperlink Types > Link is set to "Relative".

    This is not a regression bug: it makes FreeMind RC6 no worse than FreeMind 0.8.1.

    It is a nice-to-have, low-priority bug, as it is not a regression, and seems uncritical.

    --Dan

     
  • ScottyDM

    ScottyDM - 2010-02-09

    I noticed an artifact which IS related, and may even be the cause of this problem.

    Comparing RC3, RC4, and RC6 this artifact only exists in RC6. By itself this artifact is mildly annoying.

    First, I'm running Windows 2000 Pro on two different machines--a desktop and a laptop. My desktop's disks are formatted NTFS while the laptop's disk is formatted FAT32.

    This artifact is related to the legacy DOS environment and may not show up on any non-Windows platform.

    Ever since the advent of Windows NT (v3.5 for sure when using NTFS, but possibly earlier) and Windows 95, Microsoft has "broken" the 8.3 limitation for file names. In addition to storing the real file name, they also auto-generate and store a legacy 8.3 file name, for use by older software developed before 1995. See: http://en.wikipedia.org/wiki/8.3_filename

    I've tried three different methods of starting up FreeMind with a MM file. On RC4 all three methods yield the same result--FreeMind sees my MM file's path and name using only its true file and folder names--never using any legacy DOS names. HOWEVER in RC6 some start up methods use the true names and some contaminate the "pathname/filename" by populating each name with the 8.3 name, NOT the true name.

    THIS IS THE CAUSE of relative hyperlinks containing a bunch of unnecessary junk. I've never examined FreeMind's code, but my guess is that when building a relative hyperlink FM asks itself, "Where am I?" and "Where is the file I need to link to?" My guess is that the second answer contains only true names, while the first is contaminated by legacy 8.3 names. Thus, the strings can never match, and so the relative hyperlink is AFU.

    When launching FreeMind RC6 with no MM file (opens to a blank gray window), and then selecting the MM file via the menu item "File/Open..." there is no problem--FM uses only the true folder and file names.

    BUT when launching FreeMind RC6 by double-clicking directly on the MM file, OR when double-clicking a shortcut that points to the MM file, then FM picks up the legacy 8.3 folder and file names for the whole path. RC4 does not do this, either on FAT32 or NTFS.

    Partial screenshots:

    RC4, double-clicked on a shortcut pointing to MM file -- this is how it should look! http://www.skunkwks.com/web/hidden/MM/ScrCap_PrimaryMM_LaptopWin2k_v0-9-0rc4.png

    RC6, double-clicked on shortcut pointing to MM file -- this is wrong! http://www.skunkwks.com/web/hidden/MM/ScrCap_PrimaryMM_DesktopWin2k_v0-9-0rc6.png

    Note that once I launch my "root" MM file, I launch other MM files via hyperlinks on nodes within the original MM file. This is what the same partial screenshot looks like for one of these "sub-MM files" in RC4. http://www.skunkwks.com/web/hidden/MM/ScrCap_SecondaryMM_LaptopWin2k_v0-9-0rc4.png

    And this is what the same "sub-MM file" looks like in RC6. http://www.skunkwks.com/web/hidden/MM/ScrCap_SecondaryMM_DesktopWin2k_v0-9-0rc6.png

    My guess it that the fix will be to keep FreeMind from grabbing the legacy file names. Or, if that's caused by an OS glitch, to have FM somehow check the validity of the full path for the MM file and replace it with true folder and file names if/when necessary. Done when opening a new MM file, of course.

    So the workaround is even simpler than I first though. Hopefully the code fix will also be simple and this can be put to bed before the release of v0.9.0.

    Thanks a million!

     
  • ScottyDM

    ScottyDM - 2010-04-25

    EWL;

    I suspect this issue only appears on Windows.

    Once FreeMind _thinks_ the path to the .mm file is made up of legacy 8.3 names (as per Wiki article: http://en.wikipedia.org/wiki/8.3_filename ) when in fact it's made up of LFNs (long file names, as per that Wiki article) then adding relative hyperlinks fails.

    FreeMind 0.9.0 rc3 and rc4 are fine. FreeMind rc6 gets confused _only_ when it starts up and opens a .mm file at the same time. Once rc6 is running, no problems. So a work around would be to start rc6, close the .mm file, then reopen the file via File/Open or Ctrl+O.

    In my example above,
    "C:/CreativeWriting/stories/instinct_and_intellect/instinct_and_intellect.mm"
    becomes
    "C:/CREATI~1/STORIES/INSTIN~1/INSTIN~1.MM
    To Windows, these are exactly the same path/filename. To sane programs, they are not.

    Quite possibly the fix is simple. The issue only happens at program startup. This might even be a Java engine issue. There's another Java-based program with the same startup issue where the bug comes and goes with minor revisions.

    I should install rc7 and see how that does.

     
  • ScottyDM

    ScottyDM - 2010-04-25

    I am officially confused. I read the comments at the bottom of the list and thought they were new.

    But the insanely great news is that v0.9.0 rc7 works!

    Does anyone know why? Can we close this issue? There are way too many open or unassigned issues in this bug tracker.

    Thanks a million.

     

Log in to post a comment.

Get latest updates about Open Source Projects, Conferences and News.

Sign up for the SourceForge newsletter:





No, thanks