What files does `allow_file_writing` allow writing to.

[niemela]

• All files? (no?)
• Files created by the submission, i.e. files that does not exist yet? (yes).
• Files given in .files? (yes)
• Files given as included files (no?)
• Submitted files (no?)

Regardless of what the answer is, this needs to be clarified.

[Tagl]

Files created by the submission, i.e. files that does not exist yet?

I would say yes.
However, are there no conditions where editing should be allowed while creating new files is not?

Files given in .files

I would ideally like to be able to say you can write new files without being able to edit other files given.
Just consider something as simple as "Implement a copy program"
I want the file to be provided with .files and then the submission should copy the file and create a new file with the proper name.
I can then have the output validator simply check if the contents are equal.
If writing the original file is allowed then you can just make it empty and create an empty file.

Yes, there are probably other ways of implementing the problem to avoid this, but having this option makes it simple.

Files given as included files

If a file should be included with every test case, should it then be duplicated over all tests to allow it to be editable each time?
I don't mind that a lot, but that can be a lot of duplication.

Submitted files

I can't think of a case where this is needed currently.

In general, I feel like a single boolean is not enough to capture the common cases, but two booleans might be enough.
I at least see these three actions available: create, edit, and delete.
You might argue edit and delete are the same, there is an extremely minor difference between removing a file and overwriting it with empty contents.

A much more complicated option could be to mark each file that is included with read/write/execute, but that feels overkill to me.

[niemela]

Files created by the submission, i.e. files that does not exist yet?

I would say yes. However, are there no conditions where editing should be allowed while creating new files is not?

There certainly could be problems where you want to allow editing but not creating new files. That said, this can (mostly) be verified by the validator. I.e. it can just reject if you created any new files.

The "mostly" is because the validator can't see if the submission used a temporary file (i.e. a file that was created and them removed before the submission finished). Is that relevant though? Is there any practical advantage to being able to do that, that you can't get (whit just a little bit of overhead) even without? E.g. since you can edit files, you can use a section as a scratch area instead of a new file, right?

Files given in .files

I would ideally like to be able to say you can write new files without being able to edit other files given. Just consider something as simple as "Implement a copy program" I want the file to be provided with .files and then the submission should copy the file and create a new file with the proper name. I can then have the output validator simply check if the contents are equal. If writing the original file is allowed then you can just make it empty and create an empty file.

Yes, there are probably other ways of implementing the problem to avoid this, but having this option makes it simple.

That's true...

Files given as included files

If a file should be included with every test case, should it then be duplicated over all tests to allow it to be editable each time? I don't mind that a lot, but that can be a lot of duplication.

Is this a common case? Can you even think of a reasonable problem where you would need this?

If it's a very uncommon corner case, I don't mind some duplication if it makes the much more common cases simpler or better. Also, they could all be symlinks, so it's not that much anyway.

Submitted files

I can't think of a case where this is needed currently.

Please elaborate.

In general, I feel like a single boolean is not enough to capture the common cases, but two booleans might be enough. I at least see these three actions available: create, edit, and delete. You might argue edit and delete are the same, there is an extremely minor difference between removing a file and overwriting it with empty contents.

It sounds like more than two bools to me?

It's create / edit / (possibly) delete but also, on which files, input (.files) / included / submission?

A much more complicated option could be to mark each file that is included with read/write/execute, but that feels overkill to me.

Yes, unless we think that being able to edit a file is the exception (which it probably is?)

[Tagl]

The "mostly" is because the validator can't see if the submission used a temporary file (i.e. a file that was created and them removed before the submission finished). Is that relevant though? Is there any practical advantage to being able to do that, that you can't get (whit just a little bit of overhead) even without? E.g. since you can edit files, you can use a section as a scratch area instead of a new file, right?

I could see a file being used as extra cold storage memory if memory is limited but time limit is generous.
Seems rather niche though, I doubt it would come up often.

Is this a common case? Can you even think of a reasonable problem where you would need this?

I'm fairly certain I've already done this using included files.

Please elaborate.

Currently I cannot think of a case where you would want to be able to modify the submitted files that cannot be done by simply copying the contents of a submitted file and making a new one to edit.

Yes, unless we think that being able to edit a file is the exception (which it probably is?)

It's certainly not the most common case.
I'm parroting a little complaint from a teacher at Reykjavík University that students didn't go through any practice tasks where file editing was necessary, whether it was rewrite, append or in-place editing of lines.
We tried adding one but it didn't work on Kattis in the old format due to implementation details.

[niemela]

@Tagl Could you take lead on moving this forward?