When youtube shouldn't embed
-
The SIGINT signal is sent to a process by its controlling terminal when a user wishes to interrupt the process. This is typically initiated by pressing Ctrl-C, but on some systems, the "delete" character or "break" key can be used.
Technically it's an interrupt signal, which isn't a file, so you score 1/2 point on a technicality.
-
@blakeyrat said in When youtube shouldn't embed:
I know Linux sucks, but it doesn't have a clipboard?
Yes it does, Linux is not WinPhone 7 !
-
@TimeBandit it actually does not. The clipboards generally used in Linux are provided by X, not Linux.
-
@anotherusername I know, Linux is just a kernel.
But I was replying to Blakey. For him, even LibreOffice and GIMP are part of Linux
-
@anotherusername said in When youtube shouldn't embed:
Both buttons work for either images or files with exactly the same result regardless of which button you clicked.

ï‚“...also, what the hell?! Look at that raw:
:fa_cloud_upload: ![0_1460559183630_test.png](/uploads/files/1460559184486-test.png) :fa_upload: ![0_1460559189293_test.png](/uploads/files/1460559189862-test.png) :fa_cloud_upload: [0_1460559194260_test.txt](/uploads/files/1460559194823-test.txt) :fa_upload: [0_1460559202130_test.txt](/uploads/files/1460559202691-test.txt)
Why is the link text seemingly unrelated both to the URL and to the original filename? What is the significance of
0_1460559194260_test.txt
when the actual URL is1460559194823-test.txt
and the original filename wastest.txt
?I mean, I could see the justification for
[test.txt](/uploads/files/1460559194823-test.txt)
... test.txt... because that's the original filename...
Or possibly for[1460559194823-test.txt](/uploads/files/1460559194823-test.txt)
... 1460559194823-test.txt... because that's the unique filename it assigned to it...
but where the hell did0_1460559194260_test.txt
come from?
-
@anotherusername said in When youtube shouldn't embed:
Why is the link text seemingly unrelated both to the URL and to the original filename?
Because the prepend number is generated upon start of the upload, and the actual file name is generated on completion (which is returned to the client and written in the text to complete the action)?
It's clearly a Unix timestamp number. This tells me that you uploaded the first test.txt on Wed, 13 Apr 2016 14:53:14.260 GMT, and that it finished uploading on the server at Wed, 13 Apr 2016 14:53:14.823 GMT.
-
@Tsaukpaetra said in When youtube shouldn't embed:
Unix timestamp number
JavaScript timestamp, which is like a Unix timestamp but 1000 times as big.
-
@Tsaukpaetra but why? It's stupid. And why's one of them prepended with
0_
and the other isn't?@Tsaukpaetra said in When youtube shouldn't embed:
This tells me that you uploaded the first test.txt on Wed, 13 Apr 2016 14:53:14.260 GMT, and that it finished uploading on the server at Wed, 13 Apr 2016 14:53:14.823 GMT.
Nobody reading the post needs to know that. And it doesn't justify
[somearbitraryfilename.txt](somecompletelydifferentarbitraryfilename.txt)
.
-
@anotherusername said in When youtube shouldn't embed:
but why?
Why ask me? I'm not a node dev, I just gave my observations.
I'm willing to bet that the
0_
comes from some failed attempt to get the file size at pre-upload time.It's probably because the plugin was made without the anticipation of in-post meta attributes. What you see is what you get, and it's rather difficult to create things in NodeBB that aren't seen.
For images it's not that big a deal, since (assumedly) you don't see the title text (first file name thing), and aren't going to steal the image directly (hence the second file name), and need some way to distinguish multiple files that happen to have the same name (hence the timestamps).
It's a bodge, for sure. but not one I'm going to defend or attack it. It can be improved, for sure, and so long as someone is willing to do so, I'm fine with that.