Torrent file protocol - custom field - file

I am wondering if there is any available field in the .torrent files that could be used for some custom functionality in someone's implementation of a torrent client? For example, one might want to encode an URL to the file owner's website, someone else - some custom message to be displayed when opening the files, etc. Is something like this feasible in the current implementation of .torrent files?

Yes. .torrent files are just bencoded dictionaries and can hold arbitrary key-value pairs.
The main consideration when adding a custom field is to determine whether it should go into the root of the .torrent or inside the info dictionary.
If it goes into the root, it will not affect the info hash (which is the unique identifier of the torrent), and it will also not be available when downloading magnet links.
If it goes into the info dictionary, it is sort of locked down to the info-hash, in the sense that the info-hash depends on it. It will be transferred as part of the metadata when downloading magnet links and it cannot be changed (without changing the info-hash and thus creating a separate swarm).
So, if it's something you want 3rd parties should be able to change after the torrent was created, it should go in the root, if you want it to be entered once when the torrent is created and never change, it should go in the info dict.

Related

Is there a way to filter the Document chooser when it's opened from a particular block's form? [duplicate]

This question already has answers here:
Limiting file types for a specific DocumentChooserBlock() Block in Wagtail Steamfield
(2 answers)
Closed 1 year ago.
I'm writing a custom StreamBlock that is designed to render a table based on the data in a given CSV file. The CSV files will be stored in the usual Document store, so the block needs to present the Document chooser to let the user pick a CSV file.
I would like to restrict this block's Document chooser to documents whose filenames end in .csv, without affecting any other Document chooser. I dug into the code to try to figure out a way to do that, but after 30 minutes of poking around, it doesn't look like there's any obvious way to determine the source of a request to the admin/documents/chooser/ view, which is what actually renders the Document listing.
My best guess at the moment for how to do this would be to subclass DocumentChooserBlock and AdminDocumentChooser, so that I can tell it to use a custom version of wagtaildocs/js/document-chooser-modal.js. I'd change it to send an extra GET argument, or something like that, whenever CSVTableBlock's Document chooser sends a request to admin/documents/chooser/. Then I could implement construct_document_chooser_queryset to look for that custom GET arg, so it knows when to filter the documents queryset to only .csv files.
But I'm really not at all sure that this is the right way to go about it, or if it's even possible for that strategy to work. Is there a better/possible way to do this?
you actually no need to do anything, almost all use cases for such filtering scenarios, an editor can input the ".csv" in the search box of the chooser modal

Can't find a referenced R File on the SEC Website?

I am attempting to understand the 2020q1 data set found here: https://www.sec.gov/dera/data/financial-statement-data-sets.html,
and am using the reference documentation inside the 2020q1 folder as a “readme” file. The reference documentation specifies that
within the Presentation (pre) data set, the “report” field is a numeric (integer) whose “value refers to the “R file” as posted
on the EDGAR Web site.” I have found no such file after extensive search, and am left with no method of interpreting the “report”
field and all associated data. Please link to the appropriate R File or guide me in the right direction for assistance if possible. Thanks!
So a point of clarification upfront, cause this confused me as well, the "R file" in question is not a script file of the R language. Instead, it simply seems to be a report file that holds the formatted data.
So after digging deeper into the readme, I found the following detail in the description for the SUB.txt data.
Note: To access the complete submission files for a given filing, please see the SEC EDGAR website. The SEC website folder HTTP(s)://www.sec.gov/Archives/edgar/data/{cik}/{accession}/ will always contain all the data sets for a given submission. To assemble the folder address to any filing referenced in the SUB data set, simply substitute {cik} with the cik field and replace {accession} with the adsh field (after removing the dash character). The following sample SQL Query provides an example of how to generate a list of addresses for filings contained in the SUB data set:
· select name,form,period, 'http(s)://www.sec.gov/Archives/edgar/data/' + ltrim(str(cik,10))+'/' + replace(adsh,'-','')+'/'+instance as url from SUBM subm order by period desc, name
Therefore, it looks like we have to correlate each "adsh" submission ID with the "cik" company ID in order to get the link we are looking for.
Doing this for the first entry of pre.txt, we get an adsh value of "0001032208-20-000006". I simply searched through sub.txt with notepad and found its associated cik of "1032208" which belongs to "SEMPRA ENERGY". Therefore, we generate the following link: http://www.sec.gov/Archives/edgar/data/1032208/000103220820000006
From there, we find a directory of files associated with the given submission. Inside is a collection of files with the prefix of "R". Simply clicking on them will open them in your browser, using the "report" and "line" fields, we can then correlate which file we want. Notice that we can add "/R{number}.htm" at the end of the link we generated to find this folder to get a given report number.
If you know what you are looking for, doing this by hand with "ctr+f" find functionality should be fine. Otherwise, you may want to open these docs in excel to generate the links for you.

Redmine: How to link an attached file in a project from its underprojects?

Lets say I have Project A with an attached imageFile.
Then I created 10 different Projects which are underprojects of Project A.
I want to link the ImageFile of Project A to the Wiki of every underproject , so that I can see the ImageFile in the Wiki-Area of each underproject.
What im doing so far is to copy full path of the attached file of Project A in the Wiki of every underproject, like for example:
!>/attachments/download/157/schnittprofil.png!
Is there a better way to achieve that, because every time I update the imagefile, I have to renew the id-numbers of all imagefile-links in the underprojects.
Since an attachment is only actually identified by its ID and all attachments are immutable (i.e. can be changed after upload), new uploads will result in a new ID. Since multiple attachments with different IDs can have the same name, you can also not reliably find an attachment just by using its name in broad contexts.
That said, to solve your issue, you could use the include macro to include a common Wiki page in your sub-project's wiki pages which then displays the image attachment.
For that, you can create a Wiki page named e.g. Schnittprofil in your parent project where you directly upload your file. In the wiki page, just reference the image with
!schnittprofil.png!
Assuming the parent project has an identifier of project-a, you can then include the page in other wiki pages with
{{include(project-a:Schnittprofil)}}
Each time you change the page on the parent project, it will automatically also show the updated content on the child wikis. The only requirement is that the users need to be able to read the wiki of your parent project (e.g. are members of the project with the "Read wiki" permission).

How can I keep changes in the index when I use DIH fullimport?

I'm using Solr 6.5 to index files from multiples ftp files into multiples cores (having one core for each type of document, like audio file, image, software, video and documents).
The situation is that I'm doing this to populate an app that in its front end has a social networking approach in which every user can add new tags or modify other metadata without restriction.
So when I execute again data import handler to add new files to my application, it erase the index that previosly was modified for the user and set up with the data-config default configuration.
My question: is there a way to tell DIH, if the id exists, continues without importing and just adds the files which don't have an id in the index?
If this is not possible, can I do something similar in a different way?
Thanks for everything!
Sounds like you are doing a full import with default settings. One of them is clean, which defaults to true and deletes the whole index before the import.
Try setting it to false and also look at preImportDeleteQuery and postImportDeleteQuery for even more precision.

Difficulty with filename and filemime when using Migrate module

I am using the Drupal 7 Migrate module to create a series of nodes from JPG and EPS files. I can get them to import just fine. But I notice that when I am done importing them if I look at the nodes it creates, none of the attached filefield and thumbnail files contain filename information.
Upon inspecting the file_managed table I see that both the filename and filemime fields are empty for ONLY the files that I attached via the migrate module. This also creates an issue with downloading the files.
Now I think the problem has to do with the fact that I am using "file_link" instead of "file_copy" as the file operation I specify. The problem is I am importing around 2TB (thats Terabytes) of image files. We had to put in a special request with Rackspace just to get access to that much disk space on our server. So I can't go around copying from one directory to the next because of space issues. So "file_link" seems like the obvious choice.
Now you probably want to see how I am doing this exactly, so here is the code snippet:
$jpg_arguments = MigrateFileFieldHandler::arguments(NULL,
'file_link', FILE_EXISTS_RENAME, 'en', array('source_field' => 'jpg_name'),
array('source_field' => 'jpg_filename'), array('source_field' => 'jpg_filename'));
$this->addFieldMapping('field_image', 'jpg_uri')
->arguments($jpg_arguments);
As you can see I am specifying no base path (just like the beer.inc example file does). I have set file_link, the language, and the source fields for the description, title, and alt.
It is able to generate thumbnails from the JPGs. But still missing those columns of data in the db table. I traced through the functions the best I could but I don't see what is causing this. I tried running the uri in the table through the functions that generate the filename and the filemime and they output just fine. It is like something is removing just those segments of data.
Does anyone have any idea what this could be? I am using the Drupal 7 Migrate module version 2.2. It is running on Drupal 7.8.
Thanks,
Patrick
Ok, so I have found the answer to yet another question of mine. This is actually an issue with the migrate module itself. The issue is documented here. I will be repealing this bounty (as soon as I figure out how).

Resources