I am using built-in 'write file node' a lot, but it's set up automatically in a subflow. Needed to write some test data so used it manually. However it's been a while and I forgot the details of how it was used. Looking at help info, it seems it would be enough to specify msg.filename and it should be used as default? Similar to how other nodes can use specific msg props by default. But it complained about missing filename. It starts by having path, but this doesn't work, giving error "No filename specified". Change it to msg. but this requires a prop name.
Feels a bit misleading to have msg.filename in doc, when you anyway have to specify it. Wouldn't it be much better to have it read msg.filename and using it as a hardcoded default?
The default is just to accept a fixed filename string - so we can't specify an actual filename. When typed inputs were added it then allowed you to change it to be picked up from properties eg - msg.filename...
I don't need an actual filename, I need (prefer) that msg.filename is used if I don't specify anything else. What I'm seeing is write fails because no filename is given, but I have entered msg.filename in incoming msg.
Not sure I understand... the default is to expect a filename to be specured - if you don't supply one then that is an error / mistake.
Are you saying that if the filename is blank then we should assume msg.filename - even if that is not specified ?
The doc says:
filename string The name of the file to be updated can be provided in the node configuration, or as a message property. By default it will use msg.filename but this can be customised in the node.
My experience isn't that it can be provided in node configuration. I must specify it! I cannot simply send msg.filename and then it can work itself out. This is unlike the experience I have with most (all?) other nodes having default msg props.
Perhaps this is confusing?
You specify it as fixed if you choose path. Or dynamically if you choose one of the other options.
1 Like
Why can't it just use msg.filename as default convention instead? When I use http request node, I don't have to specify headers in config OR specify msg prop name (msg.headers). I can do neither, simply give it msg.headers as input msg and it solves the rest.
When I use write node, it doesn't use default msg.filename at all. It fails and says it cannot write because of missing path. If I change from path (fixed) to msg. (dynamic), it still won't use my msg.filename and it also gives error symbol warning both in node and on deploy (popup). That's a lot of hassle when it could simply be avoided by it shutting up and accepting my msg.filename. Then finally I remember (from last time a year ago when I last used this) that it was cumbersome and that I needed to add something more. It requires the msg.filename as config!
Probably because people asked for it to be more flexible?
You can please some of the people some of the time and all of the people none of the time. 
Node-RED is very flexible. This is good most of the time. But occasionally means that not everything is perfect for everyone.
1 Like
Haha perhaps too flexible for my taste. Preparing the input is something I always have to do regardless, so setting msg.filename or msg.headers or anything else is a breeze 
This is a very different design choice than most other nodes I have worked with. When I use delay node, I don't have to specify which msg prop has the delay value, I can simply use msg.delay. Same with http, exec, mqtt and... all the rest?
Comes from the fact that typedInput's were a relatively late addition to Node-RED and they are also rather a pain to program as a node developer. But, they are super flexible. I usually regret not using them up-front when creating nodes. Thankfully, I've developed some standard, better (in my opinion) styling and a helper function for the runtime complexities.
For sure, we should also not forget that doing file read/write using Node-RED as a platform is a heck of a lot easier than programming our own microservices! 
