-
Notifications
You must be signed in to change notification settings - Fork 101
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
BEP47 symbolic links to directories #127
Comments
Yes, if dangling symlinks are allowed then I don't see a reason to exclude directories. Unless there are security implications.
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.
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. |
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.
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?
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? |
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. But that would have been the case anyway since for symlinks you'd be relying on an optional BEP (Nr.47) already.
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) |
Ahh, I think I probably should have mentioned that I am working on
That's probably the best course of action in order to find the sensible defaults I am looking for. |
BEP47 writes:
I would like to ask for some clarification:
symlink path
of such symbolic links be? An empty array?The text was updated successfully, but these errors were encountered: