Created attachment 122251 [details] [review]
patch to allow following symbolic links

patch that allows symbolic links to be followed when getting directories/files

For getting directories:
 o Checks whether an entry is actually a link
 o Traverses the link to see where it ends up
 o If the link points to a directory, add it to the directory list like normal

Same process is done for files as well.

Hey

Yes, I needed this as well. Basic idea is this:

 o User has media library directory of ~/Music
 o Inside this folder are symlinks to other directories on the file system. eg:

   ~/Music/music      -> /media/disk1/music
   ~/Music/moremusic  -> /media/disk2/music
   ~/Music/videoclips -> /media/disk1/video

 o Scanning the media directory doesn't do anything because symbolic links aren't followed

The file I attached is a patch that modifies how directories are parsed in Banshee.IO.Unix.

A new method looks through a link to the file it points to, and returns the FileSystemInfo entry for that file. The new method is needed to deal with multiple level links (links pointing to links).

This method is used in Directory.getDirectories and Directory.getFiles to see whether a link points to a directory/file. eg. If a link points to a directory, the link is added to the list of directories just like the regular directories are.

Works the same way as for files.

The main issue with traversing through symbolic links is that circular links will cause an endless loop when doing the scan of the collection. My patch doesn't consider this at all - It doesn't deal with the scanning logic, it only makes it so symbolic links aren't completely ignored.

Cheers
Michael

Thanks for the patch !
Please follow the code formatting conventions described in the HACKING file : indent with spaces, etc.

I also think circular links should be handled. We don't want a scan to last forever ! ;)

Hey

Yeah I had my tab settings all messed up in vim, sorry about that.

I agree that the circular links need to be handled, I'm not entirely sure of the best way to go about it. A possible way is to keep track of a list/map of any symlinks we traverse into:

Inside Library Scan
 > On entering directory
 > if directory is a symlink
 >> if directory is in list, return
 > add link to list/map
 > scan directory like normal

Now since we are only adding symlinks to the list, the data structure shouldn't get too large. Obviously this needs some more thought and I don't have any code in front of me until I get home tonight. But yeah I'm curious to know what other people think about this, and I'll have a hack on it later.

Cheers
Michael

I'd rather have the patch in as it is since frankly a one time submitter is very unlikely to fix all possible pitfalls there are - it's already great that they are submitting patches.

Created attachment 129243 [details] [review]
updated version

This patch fixes formatting issues.

I also added a check for circular symlinks and replaced tail-recursion with iteration.

Created attachment 129290 [details] [review]
Do not follow symlinks that go up the tree

I updated Alexander's patch, so that symlinks that point higher up in the directory tree are ignored.
Without this additional restriction, the 2 following structures would lead to an infinite loop :

FolderA/
  link -> ../FolderA

FolderA/
  FolderB/
    link -> ../../FolderA

The other possibility would be to keep track of all visited folder in the DirectoryScannerPipelineElement class.
I putting this here in case someone has a better idea...

A couple problems with this

1. it creates a Dictionary for every child - that's a lot of Dictionaries!
2. it doesn't prevent all ways in which a recursive symlink could occur; as you mention Bertrand, we'd have to do this at a higher level
3. the file symlink traverser shouldn't traverse directory-symlinks, (eg getfiles for / where it contains this: /dir-link1/dir-link2/actual-file would return actual-file when it shouldn't)

Should we really even try?  Is there any legitimate use of such a symlink structure?  If we're even going to try, let's do it right.

Created attachment 133715 [details] [review]
Updated to comment #8

Updated Bertrand's patch to address all these issues.

Bulk changing the assignee to banshee-maint@gnome.bugs to make it easier for people to get updated on all banshee bugs by following that address.  It's usually quite apparent who is working on a given bug by the comments and/or patches attached.

I've seen this issue mentioned in a couple different places recently (particularly the Ubuntu forums).  This would be a nice fix to have; is there any chance that the patch still applies?

I have the same problem i can not apply the patch. 
How i can do it?

Is there any way to make this fix permanent?

This problem has been fixed in the development version. The fix will be available in the next major software release. Thank you for your bug report.

*** Bug 612838 has been marked as a duplicate of this bug. ***