BEP47 symbolic links to directories

[pobrn]

BEP47 writes:

Just like the regular path the symlink path is relative to the torrent root and must not contain .. elements. It should also target another file within the torrent, otherwise a dangling symlink will be created.

I would like to ask for some clarification:

• Is it allowed to have symbolic links to directories?
• Is it allowed to have symbolic links to empty directories?
• Is it allowed have symbolic links to the root? What should the symlink path of such symbolic links be? An empty array?

[the8472]

Is it allowed to have symbolic links to directories?

Yes, if dangling symlinks are allowed then I don't see a reason to exclude directories. Unless there are security implications.

Is it allowed to have symbolic links to empty directories?

You can't specify empty directories in the bittorrent v1 metadata format. I suppose that the v2 format semantically supports empty directories but I wouldn't rely on clients actually creating them since they don't contain any files thus aren't needed for anything.

So I'd say this is an underspecified area. You can do it if you control both the torrent creator and the downloading client, but otherwise I wouldn't rely on it.

Is it allowed have symbolic links to the root? What should the symlink path of such symbolic links be? An empty array?

That seems like the reasonable interpretation, again, barring security implications. It probably also depends on the client whether it allocates a separate directory for the root of a multi-file torrent or might download multiple such torrents into a a shared directory for some reason.

[pobrn]

Sorry for the long delay. I really appreciate your quick response (even if it has sadly taken me quite some time to reply). I find it a bit unfortunate that it is not well-defined.

You can do it if you control both the torrent creator and the downloading client

I don't, but if we entertain the possibility: what would happen with interoperability in that case? I would create my own closed "ecosystem", no? Or am I misunderstanding it?

but otherwise I wouldn't rely on it.

Could you elaborate what you mean here? You wouldn't rely on clients creating them (empty directories, symbolic links to empty directories, etc.) or you wouldn't rely on clients being able to process and download metafiles containing such entities?

[the8472]

I don't, but if we entertain the possibility: what would happen with interoperability in that case? I would create my own closed "ecosystem", no? Or am I misunderstanding it?

I assume you're asking because you have a specific use-case in mind and that particular case would be relying on a client creating empty directories which means that if implementations behave inconsistently around that area then your case would be limited to clients that do what you need. It's not necessarily a closed ecosystem, but one that relies on a client doing something that is not mandated but also not excluded by the specification.

But that would have been the case anyway since for symlinks you'd be relying on an optional BEP (Nr.47) already.

Could you elaborate what you mean here? You wouldn't rely on clients creating them (empty directories, symbolic links to empty directories, etc.) or you wouldn't rely on clients being able to process and download metafiles containing such entities?

Assuming a client already supports BEPs 47 and 52 then I would expect clients to be able to download the torrents and then may or may not create the directories or symlinks. Of course there always is the possibility that some implementation out there barfs on some unexpected data, even though it shouldn't since bencoding is an extensible format.

As I said previously, the specs seem to semantically support that use, so I'll suggest testing what you're trying to do with an existing open source implementation and maybe forking it or submitting PRs if it doesn't do what you need. If that works out the BEPs can be updated to mention the optional semantics (many use-cases probably don't care about empty directories)

[pobrn]

I assume you're asking because you have a specific use-case in mind

Ahh, I think I probably should have mentioned that I am working on mktorrent (torrent creator), that is why I wanted to know if maybe these things are set in stone somewhere that I did not notice.

I'll suggest testing what you're trying to do with an existing open source implementation

That's probably the best course of action in order to find the sensible defaults I am looking for.