So far, no validation was performed on the filenames of input nodes that
would be written to the working directory that could overlap with files
written by the plugin itself, such as stdout and stderr. This could
lead to unexpected results and often calculations failing completely.
For example, if a SinglefileData would be written to the working
directory with the filename stdout, most likely because the filename
attribute of the node was set to this, then this would be overwritten by
the redirection of the stdout, which is redirected to the file stdout
by default.
A distinction is made between clashes that happen "implicitly", meaning
the filename of the SinglefileData or FolderData just happen to
overlap, compared to "explicitly" where the user specifies a conflicting
filename in the filenames input. In the latter case, an exception is
raised during the validation. In the former case, the target filename is
automatically changed to a unique filename to resolve the naming issue.
This solution is chosen because this will happen often in normal use
cases of aiida-shell. For example, if a command is run whose stdout is
captured, it will be stored as a SinglefileData with the name
stdout. If this in turn is used as an input for a next command, this
filename will clash as stdout is a reserved name. This would force the
user to manually correct the problem by defining an alternative name in
filenames. Since this will occur so often, it is better to have the
plugin automatically solve this conflict.
There is a special case for the FolderData where an object contained
within it overlaps with a reserved filename. In this case, the strategy
mentioned above of automatically renaming won't work because the writing
of the contents is not done by the plugin but by the engine. Instead, an
exception is raised. Unfortunately, this is not done in the input
validation and so this will result in an excepted process. However, it
is currently not possible to put this logic in the input validation as
this would require significant refactoring.
Fixes #68
So far, no validation was performed on the filenames of input nodes that would be written to the working directory that could overlap with files written by the plugin itself, such as
stdout
andstderr
. This could lead to unexpected results and often calculations failing completely.For example, if a
SinglefileData
would be written to the working directory with the filenamestdout
, most likely because thefilename
attribute of the node was set to this, then this would be overwritten by the redirection of the stdout, which is redirected to the filestdout
by default.A distinction is made between clashes that happen "implicitly", meaning the filename of the
SinglefileData
orFolderData
just happen to overlap, compared to "explicitly" where the user specifies a conflicting filename in thefilenames
input. In the latter case, an exception is raised during the validation. In the former case, the target filename is automatically changed to a unique filename to resolve the naming issue. This solution is chosen because this will happen often in normal use cases ofaiida-shell
. For example, if a command is run whose stdout is captured, it will be stored as aSinglefileData
with the namestdout
. If this in turn is used as an input for a next command, this filename will clash asstdout
is a reserved name. This would force the user to manually correct the problem by defining an alternative name infilenames
. Since this will occur so often, it is better to have the plugin automatically solve this conflict.There is a special case for the
FolderData
where an object contained within it overlaps with a reserved filename. In this case, the strategy mentioned above of automatically renaming won't work because the writing of the contents is not done by the plugin but by the engine. Instead, an exception is raised. Unfortunately, this is not done in the input validation and so this will result in an excepted process. However, it is currently not possible to put this logic in the input validation as this would require significant refactoring.