When a linux client adds a directory as a share base, and that directory contains symbolic links to files outside any share base, alliance hashes them but refuses to share. On the next database update, the same files are hashed over and over again.
Example:
~/.share/broken/ contains a link "file.txt" pointing to /files/file.txt
~/.share/broken/ is added as the onle share base
alliance trace outputs:
[19:41:24] St> Path doesn't start with correct base! /files/file.txt /home/dukeman/.share/broken
[19:41:24] St> Could not hash file /files/file.txt: java.io.IOException: Internal error while hashing file.
The problem as far as I see it is this: java.io.File.getCanonicalFile() as called in org.alliance.core.file.share.ShareScanner.scanPathRecursive() resolves symbolic links to get the actual file pointed to.
The desired behaviour is for Alliance to simply treat links as regular files/directories and not care where the actual data resides.
Suggested fix: replace file.getCanonicalFile() with file.getAbsoluteFile() in ShareScanner and FileDescriptor according to the attached patch.
I have not tested this change on windows. Is there any particular feature of getCanonicalFile() which is required?
Modifications to filesystem path handling