mirror of
https://github.com/prasathmani/tinyfilemanager.git
synced 2026-04-26 10:55:56 +03:00
[GH-ISSUE #846] [Maximum file upload size] seems to be unused, right? #569
Labels
No labels
Feature
Feature
Is It Really an Issue?
Need More Info
Request
Security
bug
duplicate
enhancement
enhancement
help wanted
invalid
pull-request
question
suggestion
wontfix
No milestone
No project
No assignees
1 participant
Notifications
Due date
No due date set.
Dependencies
No dependencies set.
Reference
starred/tinyfilemanager#569
Loading…
Add table
Add a link
Reference in a new issue
No description provided.
Delete branch "%!s()"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
Originally created by @MoonLord-LM on GitHub (Aug 28, 2022).
Original GitHub issue: https://github.com/prasathmani/tinyfilemanager/issues/846
@smalos commented on GitHub (Sep 7, 2022):
Yes, it looks like.
@redherring917b commented on GitHub (Oct 17, 2022):
Is this true, that $max_upload_size_bytes and surrounding logic is unused in / by Tiny File Manager? Odd if so, but ok.
I've set both my php.ini settings of post_max_size and upload_max_filesize to 5M. The upload behavior is odd though. Files that are clearly larger than 5M (test was 11M) but less than "some" value appear to be uploaded successfully by Tiny File Manager (shows progress bar and check mark), but then do NOT appear within the visible file structure (ie. are NOT actually uploaded). Other files that are larger still (test was 16M) receive the friendly "this file is too large" message as they should.
Does anyone have any thoughts on this? I didn't anticipate that this would be an issue as restricting upload by file size - at least "approximately" enough - and properly messaging the user accordingly seemed like it would be easy and would adhere to the max upload size setting.
Thanks.
@redherring917b commented on GitHub (Oct 17, 2022):
Wanted to add that there may possibly be a filetype (aka extension) related angle to this oddity, where some filetypes are handled properly per the limits set while others are not - this still needs to be confirmed.
Thanks.
@redherring917b commented on GitHub (Oct 18, 2022):
Wanted to comment that we discovered that the following setting in the tiny file manager script that configures Dropzone
maxFilesize: 10000000000
is, despite the default size, actually in MB. And as such, changing this value to simply 5 successfully restricts file uploads to 5MB's.
While this seems to resolve the issue, it is still odd as it means that tiny file manager is ignoring its max file size setting ($max_upload_size_bytes) and using this one for dropzone. i'd still like an answer on that... why the $max_upload_size_bytes seems to be ignored.
Thanks.
@prasathmani commented on GitHub (Nov 19, 2022):
This issue is addressed in the new release.