How to enable atomic file operations for Upload and Save

[gingerbeardman]

Background

By default filebrowser make changed to files in-place. This is known as a non-atomic file operation. The benefits are that it is quicker, but the problems are that the web server may not know that the file has changed and serve a cached version, or worse serve a truncated version, or some bad data when the updated file is larger or smaller than the original.

Solution

filebrowser offers some settings mechanisms to get around this: Settings > Global Settings > Command runner

We can use the Command runner to achieve atomic file operations for upload (replacing files with a new version) and save (using the built-in text editor) by deleting the original file before the action completes.

Upload (replacing files with a new version)

Before Upload:

rm "$FILE"

Save (using the built-in text editor)

Before Save:

rm "$FILE"

Save (using the built-in text editor), alternative:

Before Save:

cp "$FILE" "$FILE.bak"
rm "$FILE"

After Save:

rm "$FILE.bak"

Ideally I'd only delete the backup file if the new file has been successfully created, but I've not been able to get that to work (After Save I'd want do test -f "$FILE" && rm "$FILE.bak" to achieve this, but it gave a server error)

[gletiecq]

I can't imagine linux having a problem with a cached version of a file being ignored to put a different version on the disk hardware. If this were a problem, it would be showing up all over the place and be a major annoyance, and not just with filebrowser. Can you describe a scenario where this actually happens?

[gingerbeardman]

Sure, I missed that out of my OP, but I did mention config in my security concern report to filebrowser admin.

But rest assured I didn't solve or workaround a problem that doesn't exist 😉 I value my time.

It happens for me on:

• filebrowser 2.28.0 (docker)
• elsewhere i use an nginx web server in a docker container to serve websites

---

Example 1:

• file contains: "23"
• change file to: "123"
• (updated file is larger)
• browser shows: "12"
• file served is incomplete/truncated

Example 2:

• file contains: "testing"
• change file to: "test"
• (updated file is smaller)
• browser shows 502 error
• page cannot be viewed

Example 3:

• file contains: "test"
• change file to: "atom"
• (updated file is same size)
• updated content is not shown

Eventually, web cache will expire and cause the correct file to be seen.
Or web server can be restarted or the cache cleared manually.

---

Server logs:

• pread() read only 3809 of 3950 from "/var/www/htdocs/index.html" while sending response to client, client: 12.34.56.78, server: example.com, request: "GET / HTTP/1.1", host: "example.com" (equivalent to 502)
• you can google the above phrase to see many reports related to badly behaving apps
• there are other errors depending on if the updated file is smaller/larger/etc

Notes

• all good FTP apps and web editors do atomic files transfer for many reasons
• filebrowser also does web FTP so I think it should do atomic transfers just to be a good server citizen
• i have a workaround so that's a relief

Started featured request #3152