ID:133672
 
I'd like for there to be some way of validating the file a client provides for the as file argument to a verb or input. It's all too easy to send an "as file" argument and be given a garbage file in return.


I'd like one of the two possibilities:

1) "as file" could be the general case, and we could also gain access to "as filesave", "as filetext", "as filedata", etc. for more specific cases. This is the client-side version.

mob/verb/load_file(datafile as filesave)
//Only accepts a savefile, otherwise the client
// will report an error on loading and no data will be
// transmitted to the server.
var/savefile/F = datafile
F[""] >> src



2) A new filetype() procedure which would return constant values in a similar fashion, which we could use to confirm the file type of any provided "as file" input. This is the server-side version.

mob/verb/load_file(datafile as file)
if(filetype(datafile) != FILE_SAVEFILE) return
var/savefile/F = datafile
F[""] >> src


An optional bonus feature: as ext("sav","txt") which would allow you to control the extensions of files shown using the standard Win32 file dialog. Intended to be used in conjunction with the as file flag.
It would be nice if the client sent ahead the length/size of the file so it can be rejected before the 10 MB file is sent to the server...

-- Data
Option 1 won't work since there is no standardized extension of a savefile, but in conjunction with the Bonus feature, it would be perfect!
In response to CaptFalcon33035
CaptFalcon33035 wrote:
Option 1 won't work since there is no standardized extension of a savefile, but in conjunction with the Bonus feature, it would be perfect!

I'm actually hoping the feature would be much smarter than checking the extension: it would have to validate the actual data in the file. It wouldn't be too hard to scan for a certain subset of IBM-extended to determine if a file is text or binary data. If it's binary data, it would then be run through a validator routine to determine whether it's a sound, icon, or savefile. If it's none of those, it would be considered an arbitrary "filedata".
In response to Jtgibson
I hadn't even thought of filtering the file after it had been selected. I originally thought you meant to scan every file in every directory as it had opened. Good idea.