9

When I save a shortcut from Firefox to disk, this is its contents when viewed in a text or hex editor.

[InternetShortcut]
URL=http://superuser.com/
IDList=
HotKey=0
IconFile=C:\Users\Jerry\AppData\Local\Mozilla\Firefox\Profiles\e8oe2h15.default\shortcutCache\ndPGaHoK9RbB9Xs6pYDwiA==.ico
IconIndex=0

It appears very simple: plain text with some markup in a file.

Let's say I want to recreate this file manually.

  1. I create an empty text file.
  2. I paste the contents above into it.
  3. .. save the file and exit the program.
  4. .. change the file extension from txt to url.
  5. .. accept the risk of loosing file type association by clicking YES when prompted.

1

Now, I would expect to be able to open this file in my default web browser by double clicking on the file icon. But no, it doesn't work like that. Instead, I receive an error message.

2

The target "" of this Internet Shortcut is not valid. Go to the Internet Shortcut property sheet and make sure the target is correct.

What exactly is meant by target ""?

By searching here on the site, I can see that several other users have stumbled upon this or similar difficulties with Internet Shortcut files, and some have even attempted to create "cross platform" Internet Shortcut files. What I don't see is why this is such a pain in the first place.

It's supposed to be just a simple file with a URL address that opens in a web browser. So what makes these "Internet Shortcut" files special? What makes them tick? When I compare my file with the original, they appear to be identical. So where exactly is the problem then?

Update


Here's some interesting findings. The word "target" likely means URL, and "Internet Shortcut property sheet" most probably refers to "Web Document" tab on the file properties dialog box. If I remember correctly it was titled "Internet Shortcut" in previous versions of Windows (in Windows 98 at least). It appears to have been renamed to Web Document since then.

There is more to it! As can be seen from the screenshots below, my file shares the same SHA1 digest as the original. But it does not share the same file icon, nor does it have the "Web Document" tab.

original file properties new file properties original file sha1 new file sha1

What's even more is that when I rename my new file so that it begins with an upper case letter, it becomes a functional Internet Shortcut file. Just like that! It just starts working. If I rename it again, so that it starts with a lower case letter, it stops working... again. Don't take my word for it, have a look at the screenshot below.

new file properties with new name

It also helps starting the file name with an underscore, a dash, a point, a parenthesis, curly brace, square bracket, equal sign, number sign, exclamation mark, and so on. It even properly replaces the globe icon with a blank paper sheet icon. Renaming it to anything other than test or Test really changes the icon.

But what's causing it to behave or misbehave like this? For instance, why would it matter if the file name begins with an upper case letter? There is no such limitation for regular files...

Update 2


If the new file's name starts with an upper case letter, prior to changing the name extension, and then gets renamed so that it starts with a lower case letter... then it still works!

So if you go about it like this, it will work:

newfile Lancelot.txt
pastein Lancelot.txt
rename Lancelot.txt Lancelot.url
rename Lancelot.url lancelot.url

a b

Update 3


It is likely that the original problem with the test.url file occurred at step 4 above. I had initially created a file named test.txt on a different disk and renamed it test.url. This was before I created a second file with the same name on the system disk in Desktop folder (as depicted above). I do not recollect, but it is likely that I initially created a file, changed the name extension, and then pasted in the target URL and saving it and hoping for it to work by a simple double click. As opposed to creating the file, pasting in the target URL, and then changing the name extension.

6
  • I can see nothing wrong with your method. It works here using your copy/paste [aside from a missing icon, of course] - target"" is what should be listed for URL: in Web Document when you open the property sheet… here that correctly shows http://superuser.com. I'm testing on WIn7 though, don't have 8.1 to try.
    – Tetsujin
    Apr 7, 2015 at 9:46
  • @Tetsujin Check your file name. Does it start with an upper or lower case letter? If upper case, try lower case. Else... then that's really strange.
    – Samir
    Apr 7, 2015 at 10:26
  • I have one called 'net shortcut.url' & another simply called 'New Text Document` - windows seemingly is hiding the .url even though I have it generally set not to; I did initially change .txt to .url
    – Tetsujin
    Apr 7, 2015 at 10:35
  • Never mind. I lost track of things. I now started off with a baby boy.txt file and renamed it to baby boy.url and it worked. I renamed it again to say baby.url (extension hidden) and it still worked, as did Baby.url. I figured it might have to do with using more than one word for name. Now all of a sudden I was able to create a blank test.txt and past into that and rename it to test.url and it worked. Huh?! I have no idea what's going on here anymore. Behavior appears to vary by the weather. It was sunny before, but clouds are building up now and it might start to rain.
    – Samir
    Apr 7, 2015 at 11:01
  • 1
    Just to verify I did a reboot and yes, I can now create test.txt and rename it to test.url and it will work. Go figure! It would appear that previous "baby boy" in a file name somehow set it straight. Windows got offended?
    – Samir
    Apr 7, 2015 at 11:10

1 Answer 1

9

I think I got something. As I suspected, Windows somehow internalizes (remembers) the names you have previously used for Internet Shortcut files. I have done some experiments using Windows 10 TP. I will try to sum up what I have learned so far. The screenshot below shows the icons and names of the files I have been experimenting with.

icons

I will refer to them by number, from left to right, or by name.

  • Number 1 was created from Firefox by drag and dropping the favicon to the desktop. I used this one as a reference. It is working.
  • Number 2, 3 and 6 were created manually as blank text files. They were left empty and their name extensions changed from txt to url. These are not working: they cause the error to appear.

    error

  • Number 4 was created manually as a blank text file. The content of number 1 was then pasted into it, and its name extension changed from txt to url. It is working.
  • Number 5 was created manually as a blank text file. Its file type name and target URL was typed in manually. It is working.
  • Changing the file name (extension excluded) affects the function (whether or not it actually works) of the file in one of two ways.

1: If the content of the file was properly defined prior to enabling it (by setting url extension), it will not be affected by a name change. It worked before the change, and it will work after the change.

2: If the content of the file was not defined (e.g. blank file) prior to enabling it, it will not be affected by a name change. Changing the name alone won't help. It didn't work before and it won't work after the change. Additionally! The new file name will become unusable later on, should you decide to change the file name anyway without properly defining the content (or leaving it blank) and you later on come back to add proper URL definition (read on for explanation).

  • Changing the file content affects the function of the file in one of two ways.

1: If the content of the file was properly defined previously, the file will still work, as it did before. But all changes made to the file will be ignored. In fact, all content can be removed and the file will still work. To commit any changes the file has to be saved under a new file name, one that has never been used before. Letter casing counts, so making changes to test.url and saving it as Test.url (if previously unused) is considered a new file, independent of test.url file. Any additional changes will have to be saved under yet another file name, one never used before. So on and so forth.

2: If the content of the file was not defined previously (e.g. blank file), it won't help defining it now by making changes to the content and saving these changes. All changes will be ignored. If it didn't work before, it won't work after the changes. To commit any changes, the file must be saved under a new file name, one that has never been used before (a new file with unique new name).

File contents

Contents of number 1, 2, 6:

[InternetShortcut]
URL=http://superuser.com/
IDList=
HotKey=0
IconFile=C:\Users\Jerry\AppData\Local\Mozilla\Firefox\Profiles\bcf6rzuf.default\shortcutCache\ndPGaHoK9RbB9Xs6pYDwiA==.ico
IconIndex=0

Contents of number 3 and 4: They are blank!

Contents of number 5:

[InternetShortcut]
URL=http://microsoft.com/

Conclusion

There are two key facts to learn here.

  1. File needs to contain a valid "target" (i.e. URL address) and file type name (Internet Shortcut) before the name extension is altered (or added).
  2. Used names cannot be reused for a different target URL. Not even after permanently deleting the original file.

Updates


It appears that opening the file in Internet Explorer (in case you are using Firefox or another third party browser) once might have the effect of fixing the broken URL file. I have seen it happen here on Windows 8.1 with IE version 11. But as explained before, the URL file content needs to be properly defined before being open in IE. The IE will then reinterpret the content, and even add a nice favicon as a file icon, essentially healing the file by adding any missing "Web Document" property. However, it did not fix my test.url file. So it may not work for all files, and I am not sure why.


I found this registry edit to be helpful.

  1. Run regedit.exe
  2. Navigate to HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Internet Explorer\Main\FeatureControl
  3. Create a new key titled FEATURE_URLFILE_CACHEFLUSH_KB936881
  4. Navigate to FEATURE_URLFILE_CACHEFLUSH_KB936881
  5. Create a new dword titled iexplore.exe
  6. Set value of iexplore.exe to 1
  7. Reboot

Source: Microsoft (KB936881)

After doing that, my test.url file finally started working, and it received a Firefox icon in place of the globe (see the screenshot in question). This fix originally applied to XP, Server 2003 and Vista. But apparently it works on Windows 8.1 as well (not tested on Windows 10).

The cause for this error – given in the Microsoft KB article – is not very detailed, but it does say following.

This problem occurs if the Windows shell receives a notification during the process that creates the Internet shortcut file. This notification is received before the file has been completely written to the disk.

It doesn't say what is meant by "notification" exactly.


As I suspected, Windows is using some Internet Explorer components to interpret these Internet Shortcut (URL) files. So whatever content you put in that text file is only used for initial interpretation. Once you change the file name extension to URL, you have changed the file association, and thus the file content will get interpreted by Internet Explorer. If properly structured, it will turn it into a working URL Internet Shortcut file. Otherwise (like leaving it empty and changing the extension) you will get the dreaded error when you try to open it.

The actual shortcut is stored elsewhere, not in the file itself, and the original file can therefore be left empty as a 0 byte file once the initial interpretation and file type conversion has been done. The file will only serve the purpose of merely pointing to the shortcut data. The shortcut data being the "Web Document" field which is stored within the NTFS file system.

The whole business with not being able to reuse a file name, or the way that you get that globe thing as your file icon (or favicon, or browser icon), it has to do with the way Internet Explorer caches web content. So in reality, when you double click on one of these URL files, and you have Firefox set as your default web browser, it's really not Firefox that's opening the URL; it's Internet Explorer! It's through some internal Windows wizardry that Internet Explorer then passes the URL to Firefox, Firefox starts and loads the URL and you see the light (page). You are left feeling proud about not using Internet Explorer.

To remove any cache that prevents you from renaming the file, or to force Internet Explorer to reinterpret the same file with the same name once more (like after modifying its content), you need to clear out some of the caching folders. This is referred to as TIF or Temporary Internet Files.

  1. Open %localappdata%\Microsoft\Windows\INetCache
  2. Select all files (ctrl+a).
  3. Delete (del)!
  4. Yes
  5. Try double clicking on your modified URL file now. It should work.

This should work for Windows 8, 8.1 and 10. You will find this folder in other locations in previous Windows versions. In Windows 7 I think it's in the same location as above, up to Windows level. There should be a folder then called Temporary Internet Files.

8
  • 1
    If someone knows what part of Windows is responsible for this behavior, and how it can be reset so that file names can be reused for new target URLs, please fill in the gaps. I have yet to find a way to do that. On that note: I received the latest 10049 of Windows 10 TP today, and in that upgrade process, all the shortcut files above have been reset, such that they are all working now. All except the "Boston" shortcut which was left empty. Number 2, 3 and 6 have also received the SU favicon as a new icon, as part of the reset.
    – Samir
    Apr 7, 2015 at 22:09
  • 1
    Does Windows cache the contents of .url (Internet Shortcut) files? says MUICache, but I'm not sure since regedit shows nothing .URL-specific there.
    – Karan
    Apr 7, 2015 at 23:35
  • That registry key appears to hold "application company" and "friendly app name" for dll and exe files. I assume it has to do with localization and displaying these names for those who use Windows in a language other than English (hence MUI).
    – Samir
    Apr 8, 2015 at 9:50
  • 2
    Like so many times before, Internet Explorer is the culprit for strange behaviors in Windows. Not to mention security problems.
    – Samir
    Apr 8, 2015 at 12:08
  • Congratulations on some in depth sleuthing, and thanks for sharing it here. Nothing you say makes me want to go back to a Microsoft platform. How can they mess it up in so many ways - I never cease to be amazed.
    – Floris
    Apr 8, 2015 at 20:48

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.