VL: FileWriter(String) can't create a folder?

Could it be that in Beta36 FileWriter(String) in VL can’t create a subfolder on its own?

Check the help patch attached. Seems really weird that it wouldn’t be able to do that? It just fails basically if I specify a path to a subfolder that doesn’t exist. Or is something else causing the error? But I can’t see what it could be.

Am I not getting something or is that not one of the most basic tasks of a file writer?


filewriter_broken.v4p (4.3 KB)
filewriter_string.vl (10.2 KB)

I wouldn’t say its broken, but I understand what you mean. You have to be quite explicit.
In C# you would do something like this:

Hm, okay, what’s strange though is, that other FileWriters, like the FileWriter(XML) don’t seem to have this limitation. Also all the vvvv filewriters don’t behave like that, so its strange that it would just turn red. Also it bangs “completed”, which is not right. Otherwise the completed bang is pointless. You have to be able to assume that it means “completed successfully”. Also would be nice if it would output an error state, especially since the error is not shown persistently. So what you end up doing is permanantly enabling write so it runs every frame and you can see what it does. Of course that’s kind of a bad way of debugging.

I think for the time being I will rely on vvvv file writer nodes. VL file nodes are too low level for my liking.

Little anecdote; I used the VL DeleteFile node to delete presets when pressing a button and one of the inputs was deleted, so deletefile only had a “parent” node going into it with no path as it should have. Clever as it was as soon as I pressed delete in the UI it started deleting ALL subpatches (so it assumed to delete the parent of itself) - that’s over 200 v4p files deleted, plus vvvv version was unusable afterwards since it must have deleted some stuff in there too. vvvv froze and crashed but 4 hours work were gone since that was the time since the last commit and deleted files don’t go in the windows trash, but they just get full on deleted with 0 warning. So yeah, gotta be careful with those file nodes!!

I think the filewriter nodes in VL should just have a boolean flag for “create directories”. That way you don’t break any already built things and in the future you can get the same functionality as in vvvv. It is really nice to have asynchronous file writing, but I thought the whole point of vvvv and VL is to simplify things as opposed to writing code where sensible.

Do you know if CreateDirectory is also asynchronous? Wouldn’t you also have to check again before writing if it really does exist now to make sure it doesn’t fail? Doesn’t the operating system take care of those kinds of processes and checks?

you’ve hit a ‘bug’ in that node and @guest showcased how to extend the node with this functionality. the only issue i see here is, that there’s no possibility to contribute that 'fix/extension back to the corelib atm.

i remember a similar problem with some older filewriter node some years ago - it didn’t create a directory and in case this didn’t exist, it failed. back then we all had to wait until a devvvv fixed that node and a new beta was released.

imho VLs purpose isn’t simplifying things. i use it to push boundaries i have with vvvv in bigger/complex projects/scenarios. for example, being able to write things to disk asynchronously while some rendering is going on.
i think the real power is, that one can use it high-level, but at the same time has the ability to change a low level behaviour (like your filewriter problem) even during runtime while patching.

nope, i don’t think so, but there’s ways to make it async.

regarding the anecdote:
that’s a pity and shouldn’t happen.
but i’m not sure which node you used. i don’t have a DeleteFile in my nodelist. what i have is a Delete [IO.Path] (which also has the option to use the recycle bin which defaults to true). there’s also a Delete [VL.Lib:IO.Path] but this one is filed under external, so it might be more low-level or advanced. i just tested both nodes with empty paths as inputs and nothing gets deleted…

@sebl Thanks for your input. I agree with your points.

It would just be nice to have this functionality already built in at the lowest level, which is how it is done in the vvvv nodes. Sensible things are just nice if they are there. If things fail its nice to be able to debug it easily, which right now in VL is simply not the case. Sure, its doable, but its just not nice. You get the most cryptic text box on hover, but only during the error. So especially with asynchronous nodes, that’s for like a fraction of a second. Can’t it just show me the “last error”. Constantly triggering an error just so I can actually see the error is not good. So if the choice is between making a node that has a limitation which will in 99% of case have to be prevented (ie. in 99% of case we will have to build the check directory, create directory, then write pattern) or if not prevented will cause an error that is really hard to debug, then both of those are not good and can be easily prevented by just adding those few lines of code to the original code of the filewriter. As an added benefit you would have a filewriter in vvvv and vl that works the same.

I will check again which delete node I used and if I can recreate what happened. I think it was one of those unfortunate chains of events. In any case, the result was pretty shitty, but I am not blaming anyone for that. Probably should blame myself for not committing more often.

there’s a setting called ‘RuntimePauseOnError’ which sounds like you want to have this enabled.

That DOES sound like something I would want. Where can I enable that setting?

So yeah, gotta be careful with those file nodes!!
Yikes! I’m gonna call that a Windows 10, from now on.

When you have the vl patching environment open click the grey quad in the top left corner, go to “Settings → Open in Editor.”

This opens an xml file in whatever editor xml’s are assigned to. In there you can set the attribute to true.


It is very useful for times like this when you are bug testing. It will slow you down a fair bit so I tend to only use it for that purpose, though that tends to be more often than not these days

Just checked out the different Filewriter VL nodes and I think I know why the String, XML and JSON versions work so differently and have different outputs - they all use completely different low level nodes inside them.

Filewriter and Filewriter(String), which are almost identical use the Writer(String) [IO.Stream] classes, which only output Progress. Once progress has turned of it creates a “on completed” bang.

But of course that is vastly different from the “success” bang that Filewriter XML and Filewriter JSON output. Those 2 nodes actually use a Save [XML.Dev] and Write(String) [IO.Stream] nodes. Write(String) [IO.Stream] is internally quite different to Writer(String) [IO.Stream] despite the very very similar name, which I think is part of this confusion.

Ill build a Filewriter(String) using the same components as the Filewriter(JSON) and see if that’s better.

@Devs: Whats the reason they all use different low level nodes? Is one better than the other? Is there a reason they all have different capabilities? I kind of have a feeling that it wasn’t really the intention, but just what happens when stuff is still basically WIP, as VL is, at least as of beta36.

Ähm well that all has been addressed in beta37, see also blog post and my last comment https://vvvv.org/blog/vl-improved-file-io - so any reason you can’t switch to beta37?

@Elias Yes, I saw that as well, but it was a while ago. Sorry, should have remembered that it was fixed.

I can’t switch to beta37 yet, because all the serialize and deserialize nodes we built for all our custom data types don’t work any longer and need to be rebuilt. So right now its: red nodes… red nodes everywhere… :/

actually this is double work, if you call Exists before CreateDirectory you are checking two times for exists, which is two disc reads, very slow. it’s a common mistake, even of experienced programmers. you can always just call CreateDirectory, naturally it already checks for existence before doing anything.

@tonfilm. I did some research and actually found the same. CreateDirectory already checks and writes the folder only if necessary. Here is what I settled with:


Of course one drawback is that CreateDirectory can’t handle a file path, but only a folder path, so you have to give it the folder then combine in the filename after CreateDirectory before giving FileWriter the path. Otherwise it will just create a folder with the filename as its name. I’m sure the new VL nodes already consider that and you can just give it a file path and it will create only the folders. So does the Path datatype not make a distincting between the folder and filename part? Or does CreateDirectory just not consider that?

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