Error deleting a Csv

I have this error when I want to delete a csv through a timestamp, someone knows why it occurs .......

error:

Error: EPERM: operation not permitted, unlink 'C:/Users/rnb/Desktop/DatosCsvT03\Datos.csv'RR1 RR2

files are only deleted when i exit deply and log back in

Does the NR user have the authority to delete files from that folder?

There is a mixture of / and \ in there. For windows you may need to escape the \ with another so \\ - or just use / consistently

In addition to the other comments, that sounds like something is holding onto the connection to the file so that you can't delete it. Do you have another flow that is writing to the file?

Sorry, in one of the tests I changed it when copying and pasting, I have put it as it touches but it still does not work

How can I know that?

my windows user has permission

Is your windows user the user running NR? (That's about all I can offer since I don't use windows)

I have a previous flow that creates the file, once created it sends it by mail and once the mail is sent is when I try to delete the file.

if in fact when I start the node network through cmd I do it as administrator

It seems that you are right because if I disconnect the node and hit deploy again if it lets me delete the files, it seems that they remain open in the process and that is why it does not let me delete them automatically, I suppose that it can be forced to close the files with a node so I should let them delete them, any suggestions to be able to close them?

In a previous thread I suggested, since you are only using the file for temporary storage, that you should consider using the built in persistent context feature to store the data rather than a file as it would probably be much simpler. This is yet another example of why it would be simpler using the context.

ok, I'll give it a spin

I think if you pass in the filename to the nodes you are using to write to the file rather than specify it in the config page then it should close after every write - as we have to assume you may change the filename for the next write - even if you don't - whereas if you fix the filename then we try to leave it open as it's faster performance wise for repeated writes.

funciona perfectamente, gracias por la ayuda.