Symlink support (Windows Vista)

[PetSerAl]

Please add symlink support in uTorrent. When rehash torrent where some files are symlinks all fine, but when start download uTorrent says some files missing.

[fowl]

I haven't experienced this using directory symbolic links (symlinkd). Symlink support should be entirely up to the OS. Please post more info.

[PetSerAl]

Not directory symbolic links but file symbolic links.

[fowl]

Does it give you an error code? (look in the logger tab)

[PetSerAl]

Only that

[DreadWingKnight]

And what about on the logger tab?

[fowl]

So you have a symlink called "debain-500-amd64-DVD-1.iso" pointing to another file somewhere else? If the file it points to doesn't exist you'll get this error.

ps. You might have to right click and enable logging Misc Errors under Error Logging.

[PetSerAl]

Symlink points to the real file. I do force recheck and it go fine (100% ok), but uTorrent show error when I try to run this torrent.

Noting in logger tab even with logging Misc Errors under Error Logging.

[point]

Can this please be fixed? It's very frustrating for me to not be able to use symlinks, even more so as I also can't use the "Relocate" feature through the Web API to work around this issue.

Obviously µTorrent can access the symlinked files since the hash check succeeds, but trying to seed the files stops with a "files missing" error message.

In fact, seeding even works when you click the button to start the torrent while the hash check is running, but not when the hash check is complete, so this can't be much more than a simple bugfix.

Please, it's been over a year since this was reported.

[Firon]

Why are you even using symlinks on files? This is a pretty low-priority fix, since the use of symlinks on -files- is virtually non-existant (on Windows).

[point]

Hi,

I want to use symlinks to be independent of the actual disk layout. Suppose I want to seed torrents that I want to store using file names different from what's specified by the torrent, or seed multiple torrents with the same files but with different filenames.

Using symlinks I could store a single copy of the files the way I want while keeping a separate directory containing just the symlinks to those files, named and sorted according to the torrents. Currently the ways to work around this issue is to either use hardlinks (which is inconvenient because they can't link to different partitions, and I also have to make sure I delete them all whenever I want to delete a file) or µTorrent's Relocate feature (which is inconvenient because it can't be automated and I would have to manually "relocate" all the files when adding a torrent rather than just pointing it at a directory with symlinks).

I do understand that this is pretty low-priority considering most users probably have never even heard of symlinks; I am certain power users will appreciate it though.

Also, the fact that this actually works right now (it's just not practical to use) makes me think it could be fixed rather easily. Hash checking symlinked files works perfectly, as does seeding (and even downloading) them, as long as the torrent is started immediately after a hash check (i.e. when adding a torrent and saving it to a directory containing the symlinked files, or forcing a hash check and then starting the torrent so that it starts immediately afterwards rather than going to "Finished" or "Stopped").

It's just when starting the torrent from a "Finished" or "Stopped" state or when µTorrent was closed that causes the error message to appear (obviously, hash checking the torrents again before starting them is not a very practical solution).

[gaby de wilde]

Client should be able to find the files all by it self before trying to download anything. Then when it finds the duplicates and cleans them up it can make an ordinary, shortcut, a symlink or a hardlink. Whatever most appropriate.

Seriously, what is this asking other people for little chunks of files that you already have? Think about it, does it make a lot of sense?

[point]

Hello,

just to let you know (this was really bugging me), I've been able to work around this issue by hooking the FindFirstFile API call, parsing the symlink target (using CreateFile and GetFinalPathNameByHandle) and switching the return value to the one obtained from the symlink target.

I would just prefer µTorrent handling this on its own; it should be easy to fix.

More information: http://blogs.msdn.com/oldnewthing/archive/2010/02/12/9962359.aspx

[armkbdotcom]

A nice use case of this when you have a torrent download folder, finished downloading, moved that download to nicely sorted and categorized folder, but still want to seed it. I made a symbolic link and was really surprised that uTorrent couldn't find it.

I'm stuck and looking forward to see the fix, if possible.

Thank you

[Firon]

You can do an NTFS junction for a folder, and that does actually work.

[fowl]

You can do an NTFS junction for a folder, and that does actually work.

That's what I do. Works fine.

mklink /J Link Target

[point]

Yes, but this thread is about file symlinks. It doesn't work with single-file torrents (unless you create an extra folder for all those torrents) or for specific files of a torrent.

I really don't see what the big deal about this is when it's just a few lines of code to check for symlinks and handle them accordingly.

To be honest though, I don't have much hope that this is gonna get implemented anytime soon but will end up like many features requested here: users being told to use a workaround that just doesn't work the same way.

I'm just glad I have the development skills to actually fix this myself (see my previous post), but I guess most users aren't so lucky.

[kalleguld]

Sorry to bump this issue again, but it is really annoying, especially since it can be fixed relatively easily (according to point).

First, Firon: Saying that a bug doesn't need fixing just because another part of the program works doesn't make sense.

And you need use cases? Suppose you download a torrent with 1000 files. You want to rename all these files (and possibly move them), and still be able to seed the files.

So you write a 2-line batch script to rename the files and leave behind some symlinks.

Relocating everyone of these 1000 files one by one is out of the question, as fixing the bug once and for all would take less time.

[mjb5311]

Bumping this one as I just ran into this issue myself, for exactly one of the use cases mentioned:

 

I have two torrents which refer to the same files by different names, like this:

• torrent1: folderX/file01, ...
• torrent2: folderY/folderX/file_0001, ...

 

To save space in folderX, I deleted torrent2's files and used the mklink command to make symlink replacements:

cd folderY\folderXdel file_*mklink "file_0001" "file01"mklink "file_0002" "file02"etc.

Seems reasonable, right? It frees up gigabytes of valuable real estate on the platters. But as discussed, µTorrent doesn't handle Windows symlinks consistently.

 

IMHO there's no reason Force Re-Check should work OK on symlinked files, but then starting the torrent should fail thinking there are files missing. The workaround of starting the torrent while Force Re-Check is in progress is nice to know about, but is obviously too inconvenient to be doing on a regular basis. So please consider fixing this bug once and for all. Point makes it sound like a really quick fix. (And I would call it a bug, not a feature request, since there is already partial support for symlinks, and presumably symlinks work fine on other OSes.)

 

This thread you're reading now is the main one, but I note this issue has been reported in other threads in 2007 and 2012, maybe more...search the Windows client forums for symlink. So although it certainly is a problem only encountered by power users, it's slightly more common than this one thread makes it seem. Thanks for your time.