Bad folder size in app

[p0358]

Describe the bug
The folder size uses /api/folder-size API endpoint, which defaults to ., being current directory:

fireshare/app/server/fireshare/api.py

Line 423 in ba97b1f

path = request.args.get('path', default='.', type=str)

But in Dockerfile, WORKDIR is set to /, so it ends up being the container's root, which not only ends up giving us completely bogus size in return, but it also often ends up in an error, since it tries to stat paths like ./proc/330/task/332/fdinfo/17 and ends up with errors like:

ERROR   app.log_exception:1455 | Exception on /api/folder-size [GET]
Traceback (most recent call last):
File "/usr/local/lib/python3.10/dist-packages/flask/app.py", line 2077, in wsgi_app
response = self.full_dispatch_request()
File "/usr/local/lib/python3.10/dist-packages/flask/app.py", line 1525, in full_dispatch_request
rv = self.handle_user_exception(e)
File "/usr/local/lib/python3.10/dist-packages/flask_cors/extension.py", line 165, in wrapped_function
return cors_after_request(app.make_response(f(*args, **kwargs)))
File "/usr/local/lib/python3.10/dist-packages/flask/app.py", line 1523, in full_dispatch_request
rv = self.dispatch_request()
File "/usr/local/lib/python3.10/dist-packages/flask/app.py", line 1509, in dispatch_request
return self.ensure_sync(self.view_functions[rule.endpoint])(**req.view_args)
File "/usr/local/lib/python3.10/dist-packages/flask_login/utils.py", line 303, in decorated_view
return current_app.ensure_sync(func)(*args, **kwargs)
File "/usr/local/lib/python3.10/dist-packages/fireshare/api.py", line 294, in folder_size
size_bytes = get_folder_size(path)
File "/usr/local/lib/python3.10/dist-packages/fireshare/api.py", line 286, in get_folder_size
total_size += os.path.getsize(fp)
File "/usr/lib/python3.10/genericpath.py", line 50, in getsize
return os.stat(filename).st_size
FileNotFoundError: [Errno 2] No such file or directory: './proc/330/task/332/fdinfo/17'
[2026-02-19 11:55:56,431] ERROR in app: Exception on /api/folder-size [GET]
Traceback (most recent call last):
File "/usr/local/lib/python3.10/dist-packages/flask/app.py", line 2077, in wsgi_app
response = self.full_dispatch_request()
File "/usr/local/lib/python3.10/dist-packages/flask/app.py", line 1525, in full_dispatch_request
rv = self.handle_user_exception(e)
File "/usr/local/lib/python3.10/dist-packages/flask_cors/extension.py", line 165, in wrapped_function
return cors_after_request(app.make_response(f(*args, **kwargs)))
File "/usr/local/lib/python3.10/dist-packages/flask/app.py", line 1523, in full_dispatch_request
rv = self.dispatch_request()
File "/usr/local/lib/python3.10/dist-packages/flask/app.py", line 1509, in dispatch_request
return self.ensure_sync(self.view_functions[rule.endpoint])(**req.view_args)
File "/usr/local/lib/python3.10/dist-packages/flask_login/utils.py", line 303, in decorated_view
return current_app.ensure_sync(func)(*args, **kwargs)
File "/usr/local/lib/python3.10/dist-packages/fireshare/api.py", line 294, in folder_size
size_bytes = get_folder_size(path)
File "/usr/local/lib/python3.10/dist-packages/fireshare/api.py", line 286, in get_folder_size
total_size += os.path.getsize(fp)
File "/usr/lib/python3.10/genericpath.py", line 50, in getsize
return os.stat(filename).st_size
FileNotFoundError: [Errno 2] No such file or directory: './proc/330/task/332/fdinfo/17'

(in this case, the direct cause is probably a race condition between listing filesystem tree and then stat-ing the files, but that's another reason not to scan / which includes dynamic folders like /proc, /dev and /sys...)

Furthermore, even after passing the video path as the parameter for a test, I noticed it returned 100 MB, which was completely wrong, even though the raw size seemed correct (the videos actually take ~55 MB). Turns out there's this rounding:

fireshare/app/server/fireshare/api.py

Line 428 in ba97b1f

rounded_mb = round(size_mb / 100) * 100

I think that rounding should be removed and just round it to 1 MB, since rounding to a whole 100 MB is very confusing and it doesn't make it look better in any way either. Instead, it just looks like it's counting something wrongly and makes you go investigate what's up with that number.

Then rounding higher units down to a single digit after the decimal separator should be fine on the other hand, when the library is large enough for that.

To Reproduce

1. Open Fireshare web UI
2. Notice that the size is either wrong or doesn't work at all

Expected behavior

1. It should only check the size of configured video path (since we care about the size of videos, not of whatever junk is in the container's filesystem), that should be the default path to check
2. It should round MB to 1 MB granularity

Screenshots
If applicable, add screenshots to help explain your problem.

Desktop (please complete the following information):

• Browser [e.g. chrome, safari, firefox]

Additional context
Add any other context about the problem here.

[ShaneIsrael]

I wonder if this somehow had to do with a mismatch python version. In my local dev my python version is newer than the version the image is built with. I'll have to check on that but regardless the path variable was definitely not set right.

[p0358]

I wonder if this somehow had to do with a mismatch python version. In my local dev my python version is newer than the version the image is built with. I'll have to check on that but regardless the path variable was definitely not set right.

Definitely shouldn't have anything to do with it. If you're developing locally outside of Docker though, then your "." folder is most likely different from "/", probably somewhere within your source tree. And hence you might have missed that one, since the size was probably closer to real and it wouldn't likely ever throw an error like that.

To be clear though, that race condition error was rather random, albeit pretty likely to happen when scanning /, but it didn't happen every time. I'm actually glad it happened to happen, since otherwise I wouldn't notice the not-shown size in the UI and wouldn't dig in to find out what's going on there.

Btw consider changing the get_folder_size() func like this too: https://stackoverflow.com/questions/75393385/how-to-efficiently-calculate-folder-and-file-sizes-in-a-directory/75406316#75406316

Only thought of this now, but that would also hopefully avoid separate syscalls for stating each file, which isn't only good for performance/efficiency, but also critically it should avoid said race conditions and errors (I imagine with a big library and on a HDD, stat-ing the library with current code can take some time, and if someone happens to remove a file in the meantime, it'd also error out)

Except maybe instead of using is_dir(), you could do is_file(), they both should be just as fast, and they both default to following symlinks.

[ShaneIsrael]

Good call, I'll look into updating the function when I have some time possibly tonight.