• 1 Post
  • 18 Comments
Joined 8 months ago
cake
Cake day: June 23rd, 2024

help-circle



  • The article is absolute trash for not mentioning this. “Their iconic keyboards…” is the closest it gets to describing them.

    Thankfully, there is a link to the patent at the end.

    Abstract

    A keyboard comprising a plurality of transparent keys. In use, the keyboard is attached to a device such as a mobile device, to overlie a display screen of the device. One or more images displayed on the display screen are made visible to a user through the keys, which may be pressed by a user. User input is determined by identifying a pressed key, and the image or part thereof visible through the key when pressed.

    Basically a detachable keyboard of transparent material as a display overlay, providing tactile feedback while the LCD allows for backlit and customizable key labels. I don’t remember seeing a practical implementation of this IRL or in media but I might be too young for that.







  • Your client must have downloaded entire chunks, including parts of adjacent files to those you wanted. I think most clients will discard them but it’s possible they are stored somewhere hidden to enable seeding them again. Pretty much every client will tell you something like “66 chunks (have 11)” and/or progress on a per-file basis, from which you can deduce which of these behaviors is used. Badly written ones will make a file as big as the previous episode to the one you want and fill it with zeros so that the few MiB are physically in the right spot. Obviously, that fills your drive with junk unless compression is enabled at filesystem level.

    It’s always better to seed something even if it’s not an entire file. Peers are usually upload-bandwidth-limited so being another person providing just a few chunks helps download speeds. Unless you meddle with their progress files, torrent clients will not announce (offer for download) chunks they cannot reassemble. Only people who have 100% of the data are listed as “seeders” in the swarm.



  • I’m willing to take the risk. It’s like saying “your web browser supports WebGL”. Unless you’re on Opera Mini or something text-based or ancient, we can assume it’s true.

    How does changing an extension break verification? It’s just a rename again. I have successfully changed an extension using qBittorrent before and the check passed again. Via its web interface, even!

    And no client hashes filenames because they just aren’t what is hashed. I think even TUI ones have internal support for different filenames even if they don’t have a rename function because you can reach limits of your filesystem (path length, character support etc.)



  • You’re wrong, partially. Stand by while I illustrate.

    Neither file names nor extensions are included in content hashes.

    Let’s first see how a torrent file is created, using quick-and-dirty bitmaps I just drew. File sizes will be in whole MiB (1 MiB = 1 pixel width) for convenience.

    So you have a file tree you wanna share.

    The client will arrange the files in some order. I think you can create a valid torrent file with any ordering but let’s just assume it’s by path, alphabetical. (We are supposing each file is a whole number of MiB, in reality it can be any whole number of B)

    Now file contents are concatenated.

    Then split into 14MiB chunks (in practice 2, 4, 8 or 16MiB but I forgot to account for border while drawing lol) and zero-padded (grey) to fill the last chunk.

    v2 .torrent files can be aligned (where large files always start at chunk border) but this is not allowed/encouraged in most trackers due to hit-and-miss support by clients.

    Now a hash is calculated for each chunk, creating a hash map. I’ll assume you know what hashing is.

    The file list, hash map, tracker info and other data I didn’t bother drawing gets packed into the .torrent file. On private trackers, each user will send a unique user ID as a parameter of the announce URL so that transfers can be tracked and users get credited for seeding.

    Any modern torrent client will let you change the names of files on your drive, provided you tell it the new filename so it can keep track of which files described in the .torrent file correspond to which files on your filesystem (therefore the recommended way is to rename within the client). Then it will be able to reconstruct the chunks so it can send them as other people request them while you seed.

    Theoretically, you should be able to also change the directory structure but I don’t know a GUI client that will let you. Maybe you can try symlinks or path traversal shenanigans like /../S01E01.mkv to un-folder the seasons for example.
    Others in the swarm will never know what new file names you used or about other files on your system. They only request and offer the contents of chunks, and will only accept them if the chunk resolves to the known hash.

    For example, someone willing to download just “S02/E01_Sit.mkv” from you will request chunks 72 to 84. Your torrent client will pull the first 7 MiB of chunk 72 from the end of “Season 1/S01E03.mkv” and the other 7 MiB from the beginning of “Season 2/S02E01.mkv”. The recipient will get all 14 MiB from you, check that the hash matches and discard the first 7 MiB, saving the last 7 MiB into “S02/E01_Sit.mkv” followed by the contents of chunks 73 through 83 and the first 13 MiB of chunk 84. I could draw the request-transfer-check-save process with my graphics but it’s been done before and I need to sleep so no more pics.

    Note that in the example above, the file Cover.jpg went missing. Its chunk will therefore not be reconstructible (in practice, the first 2 MiB that can’t be read from disk will be interpreted as all zeros and the hash will not match) and will not be advertised as available while seeding. (In fact, the user will still be listed as “leeching” in the swarm because they don’t offer all chunks for download.) It doesn’t matter that 12/14 MiB of the first chunk is available - other users will not accept incomplete chunks because they don’t match the hash and that means they have been altered, possibly maliciously. As a result, if this user is the only remaining peer in the swarm and then someone joins to download the files, they will never be able to get anything from the first chunk and their copy of “S01/E01_Lorem.mkv” will be incomplete (clients will either make the first 12 MiB of the file all zeros, creating a completely unplayable MKV file, or store the good parts in a .part file and wait for the first chunk forever - the latter can be more frustrating because if the LAST few MiB are missing in otherwise good video files they don’t appear even though they would be almost fully playable with the first approach). However, the torrent can “heal” if a seeder appears in the swarm and provides the a correct copy of the first chunk and the missing “Cover.jpg” file is restored (unless it’s set to “Do Not Download”).

    Edit: if you’re the user who deleted “Cover.jpg” (please don’t be) your client will probably detect it on restart or when reannouncing and alert you with a red row in the table and you have to take manual action to re-enable announcing for the torrent. Your options are:

    • If someone else has all of the first chunk, you will be able to redownload it and have the torrent complete again.
    • Set the file (and the next one) to “Do Not Download”, recheck and just accept that you will never seed the first chunk again.
    • Find the file on your filesystem, DDL site etc., put it where the torrent client expects it (or you can use the internal Rename tool if the path is the same except filename) and recheck the torrent to see if the file is indeed correct.

    Do you now understand why file-chunk alignment I spoke about above is critical if people keep losing files like NFOs?

    What is correct is that you cannot edit the filenames in the torrent file (even though torrent editors exist) because then its hash (known as “infohash”) would be different and the tracker would not recognize it. You’d need to reupload it but it would be likely detected as duplicate. You’ll only encounter infohashes in magnet links: they are used by the magnet link handler to verify that the torrent the server responded with is the one you wanted.


  • Renames are OK in pretty much all clients.

    • Open .torrent file
    • Select correct destination directory
    • Add Paused
    • Right-click each file/directory in the “Content” tab and rename
    • Recheck to make sure all files are found by the client and their contents have not changed; select “Do not Download” for missing or incomplete files, the correct chunks will still be seeded
    • Start seeding

    You can also use a torrent file editor to get the file names right before importing into a client. Useful for batch operations. HOWEVER, the info hash will be different so it won’t be recognized by the tracker. You can upload such file to your own tracker, though.