SoulseekQt indexes files in folders pointed to by shared shortcuts

Submitted by microwave on Tue, 11/20/2012 - 02:56
Forums: 
Soulseek General Discussion

Windows shortcuts (.lnk files) were just treated as ordinary files by SoulseekNS, regardless of where they pointed to.

The current build of SoulseekQt behaves a little differently. If the shortcut points to a folder, then any regular files in that folder are indexed as if the shortcut were actually a folder. These files are indexed and their names are visible to everyone, even if their real parent folder is userlist-only or isn't shared at all.

For example, in my public folders, I have shortcuts pointing to userlist-only folders:

C:\public\goodies.lnk -> C:\private\xyzgoodies

xyzgoodies is a folder that contains file1.jpg, file2.txt, etc.

I then share C:\public with everyone, and C:\private with userlist only. Everyone should see the public folder and its contents, including the raw goodies.lnk file. My userlist should additionally see the private folder and its contents, including the xyzgoodies folder.

The private folder works as it should (userlist only), but instead of the raw goodies.lnk file, they see a goodies.lnk folder which contains the files (not subfolders) in xyzgoodies:

/public/goodies.lnk/file1.jpg
/public/goodies.lnk/file2.txt

When people try to queue these files, the transfer always fails with a local error.

I'm not sure how you want to handle this, but it does seem to be a "security" problem, exposing unshared files. The safest thing would be to make it behave like SoulseekNS (where .lnk files aren't special).

Submitted by Nir on Tue, 11/20/2012 - 16:00.

Is this why you're getting the ghost folders you've posted about elsewhere? I agree SoulseekQt should index linked folders by default (maybe an option would be better for those who want that functionality). Thank you for bringing the issue to my attention, I will take a look at it.

Submitted by microwave on Wed, 11/21/2012 - 04:21.

No, I don't think it's related to the ghost folders. (Did you approve that post?) The ghost folders, as far as I can tell, only appear at the top level. There aren't any shortcuts pointing to these folders or their ancestors.

If you do add support to properly index the linked folders, I agree, it would be good to make it optional. But I'm not sure how it would even work...

Of course, you'd have to avoid recursion (don't index what you've seen before). And you'd have to make sure the recursion check handles subst'd folders (where a drive letter is mapped to an arbitrary folder; e.g. maybe you saw this folder before, but not with this path prefix).

Also, you have to respect permission, and this is where it gets tricky. Say there's a link to an unshared folder. Simple, you don't follow it; just pretend the link doesn't exist. You only want to index shared folders, right? The problem is that those shared folders are already set to be indexed in their actual locations. Your recursion check will kick in. So it's really no better than not following the links at all. Actually it's slightly worse: the folder will be indexed in one place, either in its actual location or in the linked location, essentially at random, depending on whether the link was encountered first.

Also there are a several kinds of folder links on Windows:

  • Shortcut: A .lnk file containing (among other things) the UNC path of a folder.
  • Folder Shortcut, a.k.a. Shell Link: a folder that contains a hidden desktop.ini + a visible target.lnk pointing to the target folder. Explorer pretends the contents of the target folder are located in the linking folder. Although Explorer natively supports these, Windows provides no tools for creating them; you have to use something like Winbolic Link. I use these instead of regular .lnk files in places where I want Explorer's folder tree to follow the link (and no, the ghost folders aren't connected, as far as I can tell). Other programs just see the raw files and don't follow the links.
  • NTFS junction: like an automatically followed symlink; must point to a folder on a local disk; NTFS only; somewhat "dangerous" as explained on the Winbolic Link site.
  • Symbolic Link: A less restrictive type of junction; target can be a local or remote file or folder; target path can be relative; NTFS only; Vista and newer only.

I haven't messed with junctions and symlinks on Windows, so I don't know if they're already supported, or what happens during Soulseek's indexing if they're recursive.

Submitted by Nir on Wed, 11/21/2012 - 11:27.

Hmm, the pattern of the ghost folders appearing as toplevel folders is consistent with what happens to subfolders of symlinked folders when SoulseekQt attempts to share them. Basically the Qt directory scanning mechanism (QDir) uses the actual, rather than relative, location of these subfolders. The receiver of the shared file list construes them as toplevel folders since there are no other folders in the list that can act as their parents.

You're right about implementing symlink functionality as an option, it's way too complicated. I've added two checks to the client to ensure that linked folders don't get indexed; First I instruct QDir not to list symlinks when reading the contents of each folder, and secondly I don't index any subfolder that doesn't start with the name of the master folder you're manually sharing. I'm curious to see how far it'll go to improve the situation on your end:

http://www.slsknet.org/SoulseekQt/Windows/SoulseekQt-11-21-2012.exe

Thanks, Nir

Submitted by microwave on Thu, 11/22/2012 - 03:01.

You might be right...I rechecked my shortcuts and found that I was mistaken when I said no shortcuts were pointing to the parent folders of the ghost folders' real counterparts. It's kind of weird though because I know I have gobs of shortcuts to folders, but only a few showed up at the top as ghost folders.

Anyway, the new client build worked; the ghost folders at the top level are gone, as are the .lnk folders. Thanks!

If I can make one request, it would be to ignore a folder if its only visible files are shortcuts. This would take care of the "shell link" type of folders described above, as well as just random folders full of links that aren't going to be indexed.

Submitted by Nir on Thu, 11/22/2012 - 13:42.

Great, thanks for keeping me posted!