This is a known tradeoff taken based on discussion with the frontend team. Actually recursively listing all the files while still making CMake’s install directives work correctly is absurdly complicated to do right

If this version has known "tradeoffs"... why don't we make the logic easier and just remove the/usr/share/netdata/web/v3/ directory?

If the dashboard contains nested subdirectories (e.g., static/css/fonts/), those nested files won't be installed or tracked in the manifest.

It does contain. We added and removed 500 MB of gifs. This PR will not remove them, right?

@thiagoftsm

ran as expected

What do you mean by that? What did you test?

This is a known tradeoff taken based on discussion with the frontend team. Actually recursively listing all the files while still making CMake’s install directives work correctly is absurdly complicated to do right

If this version has known "tradeoffs"... why don't we make the logic easier and just remove the/usr/share/netdata/web/v3/ directory?

Because the approach I’m taking here works pretty much independently of how the user chooses to update things (the only case it doesn’t work in is building by hand without netdata-installer.sh).

The static build can’t run things before the files are extracted and put in place, so weneed to track what files are installed and remove only those that aren’t part of the current version.

If the dashboard contains nested subdirectories (e.g., static/css/fonts/), those nested files won't be installed or tracked in the manifest.

It does contain. We added and removed 500 MB of gifs. This PR will not remove them, right?

The logic is that anythingnot in the manifest for the newly installed version gets removed, so yes, it will remove them.

That said,if they got installed in the first place, they would be in the manifest for the versions that they were installed in. The logic being used to generate the list of files for the manifest is literally identical to that used to generate the installation directives for the dashboard files.

Converting to draft to make it non-measurable - I found some issues while testing, give me some time.

@Ferroin, the original cleanup logic was functionally broken. I don't know what@thiagoftsm was testing 🤷‍♂️.@thiagoftsm, if you don't understand the change, please ask or don't review/approve.

Two issues causedgrep to match all files:

1. .MANIFEST contains relative paths, whilefind -print0 produced
   absolute paths, leading to unintended substring matches.
2. A blank line in.MANIFEST created an empty pattern, causing
   grep -Ff to match every file.

As a result,grep -vzFf filtered out the entire file list andxargs
invokedrm with no operands.

This change replaces the pipeline with a correct, POSIX-safe loop that:

• converts NUL-separated paths to newline-separated ones,
• strips the NETDATA_WEB_DIR prefix to match manifest entries,
• performs exact whole-line comparisons withgrep -Fxq,
• removes only files not present in.MANIFEST.

The cleanup now works as intended and handles all filenames safely.

The cleanup now works as intended and handles all filenames safely.

Handles all current filenames.

There’s areason this was using null terminated records instead of newline terminated records, that’s theonly character that is guaranteed to not be in a filename on all systems.

Separately, there are a shit ton of files being processed here, which is exactlywhy I structured this as one pipeline instead of a long form loop that invokes multiple commands for every single file.

Oh the irony, Copilot pointing out exactly what I was as I was writing my comment...

Force pushed to fix the codeproperly without wasting resources and correctly accounting for the fact that a newline is actually a valid character in filenames on most UNIX-like systems.

Separately, there are a shit ton of files being processed here, which is exactly why I structured this as one pipeline instead of a long form loop that invokes multiple commands for every single file.

Consider testing your changes before marking them ready for review.