Attachments - file name endings (extensions)
Attachments - file name endings (extensions)
I don't know whether I should start a new thread.
I'd like to suggest the ability to upload *.txt files. Thanks for your work, mods and admins!
I'd like to suggest the ability to upload *.txt files. Thanks for your work, mods and admins!
.: Track of the Month :.
Re: Attachments - file name endings
That would help me as well, stop all of these unnecessary zips showing off my ideas
- Trigger Happy
- Posts: 7134
- Joined: Sat Dec 26, 2009 9:54 pm
- Location: CZE
- Contact:
Re: Attachments - file name endings
No. Some trackmakers could decide to attach thier readmes as separate file out of .zip file with track itself. It would create mess.
My GR Racing Stats; thanks to GWR!
Re: Attachments - file name endings
What would be the problem with that?Ivo Porč wrote:No. Some trackmakers could decide to attach thier readmes as separate file out of .zip file with track itself. It would create mess.
Re: Attachments - file name endings
Ivo is right, it would be messy if it came to that. But I think that majority of uploaders wouldn't do that, I mean, why bother? It's easier to zip the readme together with the track and one more .txt file means another attachment, and the '3 attachments per post' limit is, well, limited already.
Maybe some newbies would do that occasionally, but not likely.
Maybe some newbies would do that occasionally, but not likely.
Re: Attachments - file name endings
Would it be possible to disable .txt in track(and cars) subforum but allow it in other?Ivo Porč wrote:No. Some trackmakers could decide to attach thier readmes as separate file out of .zip file with track itself. It would create mess.
- Bouncebackability
- Posts: 2320
- Joined: Mon Dec 28, 2009 12:09 pm
- Location: England
Re: Attachments - file name endings
well the problem there is that GeorgM, who asked for it to be allowed, wants to use it in the track forum for voting results of ToM i think.Mr.J wrote:Would it be possible to disable .txt in track(and cars) subforum but allow it in other?
and personally, i dont see much problem allowing it, not a lot of people use readme's and we never had an overwhelming amount of txt files on RSC, i dont think it will be used too much...
Re: Attachments - file name endings
Yes, BBA. In fact, I have no problem with disabling *.txt files, I was just wondering as it's not an unsecure file type.
.: Track of the Month :.
Re: Attachments - file name endings
I see. I think we should allow it since its not an unsecure file type and what's the problem if some newbie attaches his readme instead of zipping it once. And newbies rarely have readmes.Bouncebackability wrote: well the problem there is that GeorgM, who asked for it to be allowed, wants to use it in the track forum for voting results of ToM i think.
Re: Attachments - file name endings
Heck, how often do I put readme.txt in anything I do, and I'm FAR from a newbie!Mr.J wrote:I see. I think we should allow it since its not an unsecure file type and what's the problem if some newbie attaches his readme instead of zipping it once. And newbies rarely have readmes.Bouncebackability wrote: well the problem there is that GeorgM, who asked for it to be allowed, wants to use it in the track forum for voting results of ToM i think.
- Trigger Happy
- Posts: 7134
- Joined: Sat Dec 26, 2009 9:54 pm
- Location: CZE
- Contact:
Re: Attachments - file name endings (extensions)
OK. We discussed first between admins, then made additional talk with mods we decided not allow txt files.
Reasons are, that:
1. it would consume one slot of user's allowed 3 attachments.
2. it would create very tiny attachments in our systems (server/private discs, where it's backuped) with following consequences:
a. Every attachments needs note in database, that it exists, so it makes the database bigger because so small piece of datas, which can be in zip with track or car. We need as small database as we can have.
b. We need as small number of individual files there as possible, because with higher number files an error of any of them is more possible. This will increase the danger unnecessarily (e.g. error in database).
c. we need to backup them. Nothing is worse than downloading and storing of thousands of very small files, which we do now already. It's not wealthy for operations of our private discs and server disc and as it multiples possibility of crash of them, so why to have next group of so tiny files there? Present progress (3500 files in 350MB = average 100kb/file) is enough bad. (E.g. I have right now on HDD unburned backups, which consist of 2GB, but 23,5 thousands of files).
d. if we'll have to move the forum and upload the attachments to another server (or restore them back to this server after crash), every file is in danger to be uploaded corruptly then. And this we don't want, so we again need as lowest number of attachments as possible, not thousand of 1KB txt files.
3. if somebody has short readme, he can attach it in zip/rar of his main file, which is related to it. If he doesn't like it, he can put the text directly into text of his post (which is preferred place for text in forum from basic logic of it, not attachments!), if necessary he can e.g. hide it as spoiler from main part of post's reply.
Reasons are, that:
1. it would consume one slot of user's allowed 3 attachments.
2. it would create very tiny attachments in our systems (server/private discs, where it's backuped) with following consequences:
a. Every attachments needs note in database, that it exists, so it makes the database bigger because so small piece of datas, which can be in zip with track or car. We need as small database as we can have.
b. We need as small number of individual files there as possible, because with higher number files an error of any of them is more possible. This will increase the danger unnecessarily (e.g. error in database).
c. we need to backup them. Nothing is worse than downloading and storing of thousands of very small files, which we do now already. It's not wealthy for operations of our private discs and server disc and as it multiples possibility of crash of them, so why to have next group of so tiny files there? Present progress (3500 files in 350MB = average 100kb/file) is enough bad. (E.g. I have right now on HDD unburned backups, which consist of 2GB, but 23,5 thousands of files).
d. if we'll have to move the forum and upload the attachments to another server (or restore them back to this server after crash), every file is in danger to be uploaded corruptly then. And this we don't want, so we again need as lowest number of attachments as possible, not thousand of 1KB txt files.
3. if somebody has short readme, he can attach it in zip/rar of his main file, which is related to it. If he doesn't like it, he can put the text directly into text of his post (which is preferred place for text in forum from basic logic of it, not attachments!), if necessary he can e.g. hide it as spoiler from main part of post's reply.
My GR Racing Stats; thanks to GWR!