.replaceAll doing weird stuff

[Nahiiko]

Bug Description

When using replaceAll function inside Convert to File node (XLS,File Name param) I saw weird behavior. Indeed, the following: '{{ $json.Projects.replaceAll("y","") }}.xlsxyy' works perfectly fine, only the "y" in $json.Projects is replaced. example: '{{helloyworld}}.xlsxy' -> 'hello_world.xlsxy' But '{{ $json.Projects.replaceAll(" ","") }}.xlsx ' Looks fine when looking at the file output, but when clicking download you get an underscore OUTSIDE the js code: '{{hello world}}.xls '-> hello_world.xlsx_

To Reproduce

Expected behavior

Looks fine here, but click download and you get 'he_llo.xlsx_' instead of 'he_llo.xlsx'

Operating System

Synology DSM 7.1

n8n Version

n8nio/n8n:latest

Node.js Version

v18.19.0

Database

PostgreSQL

Execution mode

main (default)

[Joffcom]

Hey @Nahiiko

In the example you provided do you actually have an extra space at the end of the file extension or is that just a typo?

What is the actual value of json.Projects?

[Nahiiko]

Hi @Joffcom

Yeah there is a space at the end, which is getting replaced by the underscore once you download the file (weirdly not on the UI), which is exactly the issue here.

json.Projects doesn't matter here, as you can see in my reproduction, it works with '{{hello world}}.xlsx '-> hello_world.xlsx_

[mbrother2]

Hi @Nahiiko

Seem your issue is related to your OS, Mime Type of your xlsx file is 'application/x-cfb'. This is on my server, file name works normally:

My server: OS: Debian 11, n8n 1.23.0 with docker

[Nahiiko]

I'm running n8n inside docker on a synology NAS so I don't think that's the issue but here's the stack: postgres:15.4 n8nio/n8n:latest

Now that I think of it, I do run with "N8N_DEFAULT_BINARY_DATA_MODE: filesystem" enabled, could that be the differentiator here ?

[Joffcom]

I don't think filesystem should matter, I do however still need to create a file with a space at the end of the extension to see what happens although that seems like it would cause other issues as it shouldn't be there anyway.

I will see if I can reproduce this now.

[Joffcom]

Alright I have given this a test and the replaceAll() appears to have nothing to do with this, If you just have a space at the end of a filename we will add the _ to it instead of a space. This is likely because a trailing space in a filename will cause issues with some operating systems (Windows).

Based on this I believe this is protecting some users and there is actually no bug here as the alternative would be to remove the space from the end or refuse to download the file and throw an error.

What do you think @Nahiiko?

[Nahiiko]

Interesting ! indeed I didn't take the time to dig deeper and try other replacement strings, seems you're right. What a coincidence !

I think it'd make more sense to trim the space, but I guess that's just a dev choice not a bug, guess we can close.

thanks for the support!

[Joffcom]

Hey @Nahiiko,

I think for now we can move this to closed and we can chat internally and look at what other projects do to handle it.