IM project progress

[Warren Togami]

(Just reporting what was discussed on IRC.  Please correct any details.)

On 06/16/2009 02:27 AM, Atul Aggarwal wrote:
> 1. timestamp extension to libtorrent has been done. This includes adding
> timestamp to each file and saving it in the torrent file and reading and
> displaying the timestamp by dump_torrent example.  (Adding timestamp is
> done by adding information to info dict in the torrent file).

hydri told atul to look at boost::filesystem for a more OS agnostic way 
of doing this, to make it suitable for upstream inclusion.

>
> 2. As discussed on irc, we also need another extension in libtorrent
> which can handle links. As I have found, there is no mean to determine
> hard link and only link which we can handle is symbolic links. I suggest

There is no reason to support hard links here.  Treat them like normal 
files.

> we add attribute "l" to symbolic link and make our imbackend smart
> enough to handle symbolic links. (libtorrent svn repository already has
> attribute field defined and hence only symbolic link needs to be added
> to it). I don't see much use to add functionality in torrent to handle
> symbolic link (any ideas?). However, we need to explicitly check for
> security concern while making imbackend smart for handling symbolic links.
> So two diffeent approached can be:

We agreed in IRC that symlinks should be faithfully reproduced from the 
original source even if they appear to be broken or invalid.  It is up 
to the reader of the symlink (like the httpd) to not make it into a 
security issue.

It seems that if boost::filesystem is used for this that symlinks can be 
supported on Unix/Linux.  It seems that Windows lacks symlinks and 
shortcuts are not usable, so we should explicitly ignore symlinks on 
Windows.  libtorrent upstream may have more ideas there.

hydri suggested the .torrent metadata use MAX_PATH as the symlink target 
length limit.  If anything exceeds that length then it will print a 
warning during .torrent generation and be excluded from the .torrent. 
It must not truncate.  Additionally the .torrent will contain an 
additional "symlink" attribute.

Warren Togami
wtogami at redhat.com