Dynamically passing msg.filename from Watch node into File In Node

I read in this Topic I could get the full path in the File In node using the msg.filename variable created the Watch node.

Yes, the msg.filename variable has the full path:
/home/nemo/download/InFieldProductID/CSV : msg.filename : string[77]
However, setting the File In node to msg.filename throws this exception, seeing msg.filename literally:
msg : error
"Error: ENOENT: no such file or directory, open 'msg.filename'"

[{"id":"e1e43b19.744cc8","type":"watch","z":"13b9743.dd7f28c","name":"Watch InFieldProductID CSV","files":"/home/nemo/download/InFieldProductID/CSV","recursive":"","x":150,"y":560,"wires":[["dbf407c6.c03198","ac44ad92.8eede"]]},{"id":"dbf407c6.c03198","type":"file in","z":"13b9743.dd7f28c","name":"","filename":"msg.filename","format":"utf8","chunk":false,"sendError":false,"encoding":"none","x":440,"y":560,"wires":[["c56709f7.89bbb8"]]},{"id":"c56709f7.89bbb8","type":"csv","z":"13b9743.dd7f28c","name":"InFieldTemplate","sep":",","hdrin":true,"hdrout":"none","multi":"mult","ret":"\\n","temp":"RetailerGLN,Retailer,ShipmentNumber,OrderDate,CustomerGLN,CustomerNumber,CustomerLookupName,Crop,PlantingYear,UOM,ItemNumber,Description,ShortDescription,SeedBrand,SeedTrait,SeedTreatments,LotId,DisplayDescription,Quantity,Status,SeqCode","skip":"0","strings":true,"include_empty_strings":"","include_null_values":"","x":710,"y":560,"wires":[["8562be48.5b31"]]},{"id":"ac44ad92.8eede","type":"debug","z":"13b9743.dd7f28c","name":"","active":true,"tosidebar":true,"console":false,"tostatus":false,"complete":"filename","targetType":"msg","statusVal":"","statusType":"auto","x":440,"y":500,"wires":[x]}]

Perhaps a similar dropdown would be helpful for setting the Filename.


If you post code you have to do it correctly.

There is a button at the top of the area where you are entering your text/replies.

</> is the button.

I'm not understanding what you want to do.

But from memory, node-red is limited to what it can access.
I think you need the COMPLETE path to get to files.
Memory failing.

Given your example:

In a change node
You may try something like:
msg.path = "/home/nemo/download/InFieldProductID/"
and then add another line:
msg.filename = msg.path + "TomB-Pro600-RickB-2022.csv"

Then send that to the file-in node.

(Correct spelling is not promised in the above example)

Ok, sorry... As you are using the watch node....

msg.filename = msg.path + msg.filename (or msg.file - not sure)

You can see by the debug, the full name is already in msg.filename.

/home/nemo/download/InFieldProductID/CSV : msg.filename : string[77]

In the file in node you have:
Screen Shot 2022-04-09 at 8.35.14 AM
so you are telling the node to look for the file msg.filename

If you want to use the msg property 'msg.filename' leave that option blank.

(it helps to read the Help tab for the node)

1 Like

Thank for that, I DID read the Help, clearly not that closely.

1 Like

Yes, no path and filename in the text box worked.

Here is the Help text that I read:
if not set in the node configuration, this property sets the filename to read.

It is not clear.

Where is the located in GitHub? I would be willing to edit it to:
'Defaults to msg.filename, else looks for the absolute path and filename set in the text box.'

I would be willing to help add a file archive location feature as well on successful read and node completion.

How would you word it? It is explaining how a msg could send a setting in, that is why the title is Inputs and it starts with if not set in the node configuration, this property sets the file name to read i.e. if the property in this configuration is blank, it will look at the msg property.

What if the statement said:

“if not set in the node configuration, this msg property sets the file name to read”

This is the recommended behaviour for a lot of fields. How is it worded elsewhere in other nodes?

I recommended earlier: 'Defaults to msg.filename, else looks for the absolute path and filename set in the text box.'

How about:

'Defaults to the value set in msg.filename property, else looks for the literal value entered into the file name configuration. The value must be a resolvable absolute path and filename. Please note Windows folder delimiters are back-slash and Linux delimiters are forward-slash.'

The problem here is a misunderstanding as to what the help text is describing.

The Inputs table lists the msg properties the node supports. It is not intended as documentation for the individual fields in the edit dialog. But I can see how that may not be clear when there is a direct correlation between the mag property name and the label of the field.

But with that in mind, to say it defaults to msg.filename doesnt make sense as it is the documentation for what msg.filename can be used for. And the existing text does say what it means - that msg.filename can be used if the value hasn't otherwise been set in the node.

The additional info about relative/absolute paths, along with Windows paths, would go down into the Details section. And should be consistent with what is said in the other File nodes

This is definitely one of those times where I think I typed input would be a better solution.

It could be done in a backwards compatible manner whereby it defaults to msg.filename

I agree. This approach is better (from HTTP request node):


A typedInput is far more flexible....


You can default to msg.filename (which is efectively the current default) AND use flow/flobal context or compute the value with JSONata and even grab the filename from an ENV VAR.

Currently the default is a string that the user types in the filename. (Extra points if the "type" label was File (or blank ?) rather than string in this instance - just for readability)

1 Like

So a/z first, no title, default option, empty?

followed by msg., flow., global., jsonata, env ?

Like that?

For compatibility / users updating node-red...

  • if filename has a value, set the typedInput to a/z and put the value in it
  • if filename is empty, set the typedInput to msg. and put filename in it
1 Like

imho - yes :slight_smile:


This topic was automatically closed 60 days after the last reply. New replies are no longer allowed.