fabro/checkpoint.json

{
  "timestamp": "2026-03-16T11:59:45.915564Z",
  "current_node": "extract_patch",
  "completed_nodes": [
    "start",
    "setup",
    "solve",
    "extract_patch"
  ],
  "node_retries": {
    "setup": 1,
    "extract_patch": 1,
    "solve": 4,
    "start": 1
  },
  "context_values": {
    "internal.retry_count.extract_patch": 1,
    "current.preamble": "Goal: Set default FILE_UPLOAD_PERMISSION to 0o644.\nDescription\n\t\nHello,\nAs far as I can see, the ​File Uploads documentation page does not mention any permission issues.\nWhat I would like to see is a warning that in absence of explicitly configured FILE_UPLOAD_PERMISSIONS, the permissions for a file uploaded to FileSystemStorage might not be consistent depending on whether a MemoryUploadedFile or a TemporaryUploadedFile was used for temporary storage of the uploaded data (which, with the default FILE_UPLOAD_HANDLERS, in turn depends on the uploaded data size).\nThe tempfile.NamedTemporaryFile + os.rename sequence causes the resulting file permissions to be 0o0600 on some systems (I experience it here on CentOS 7.4.1708 and Python 3.6.5). In all probability, the implementation of Python's built-in tempfile module explicitly sets such permissions for temporary files due to security considerations.\nI found mentions of this issue ​on GitHub, but did not manage to find any existing bug report in Django's bug tracker.\n\n\n\n## Additional Context\n\nI think you're talking about ef70af77ec53160d5ffa060c1bdf5ed93322d84f (#28540). I guess the question is whether or not that documentation should be duplicated elsewhere.\nThank you Tim, this is precisely what I was looking for! I can only see one issue with the current docs (if you excuse me for bothering you with such minor details). ​The documentation for the FILE_UPLOAD_PERMISSIONS setting reads: If this isn’t given or is None, you’ll get operating-system dependent behavior. On most platforms, temporary files will have a mode of 0o600, and files saved from memory will be saved using the system’s standard umask. As I would understand this text, only temporary files get a mode of 0o600. I would then ask myself: \"Why should I care about temporary files, they should be gone anyway after the file is uploaded?\" and skip setting FILE_UPLOAD_PERMISSIONS. What is important but is not properly conveyed to the user is that not only temporary files themselves, but also the actual files which end up in the media folder get permissions of 0o600. Currently a developer can only discover this either by careful reading of the Deployment checklist page (manage.py check --deploy does not seem to check FILE_UPLOAD_PERMISSIONS) or by hitting the inconsistent permissions accidentally (like I did). I propose to unify the docs for FILE_UPLOAD_PERMISSIONS on the Settings page and the Deployment checklist page like this: ​https://gist.github.com/earshinov/0340f741189a14d4fd10e3e902203ad6/revisions#diff-14151589d5408f8b64b7e0e580770f0e Pros: It makes more clear that one gets different permissions for the *uploaded* files. It makes the docs more unified and thus easier to synchronously change in the future if/when required. I recognize that my edits might seem too minor and insignificant to be worth the hassle of editing the docs, committing, re-publishing them etc., but still I hope you will find them useful enough to be integrated into the official docs.\nNow that I think about, maybe Django could provide # <Commentary about inconsistent permissions when this setting is omitted> FILE_UPLOAD_PERMISSINS=0o600 in the ​default project settings so that developers don't miss it? 600 seems a reasonable default, particularly because people would get 600 anyway (at least on some operating systems) when the TemporaryFileUploadHandler is engaged.\nSince this has come up again, I've suggested on django-developers (​https://groups.google.com/d/topic/django-developers/h9XbQAPv5-I/discussion) that we adjust the FILE_UPLOAD_PERMISSION default to 0o644 (This was the conclusion I eventually came to from the discussion on #28540.) Lets see what people say there.\nThus far, no great objections on the mailing list to adjusting the FILE_UPLOAD_PERMISSION default. Thus I'm going to rename this and Accept on that basis. A PR would need to: Adjust the default. Add a Breaking Change note to releases/2.2.txt (on the assumption we can get it in for then.) — This should include a set to None to restore previous behaviour' type comment. Adjust the references in the settings docs and deployment checklist. Make sure any other references are adjusted.\nReplying to Carlton Gibson: Thus far, no great objections on the mailing list to adjusting the FILE_UPLOAD_PERMISSION default. Thus I'm going to rename this and Accept on that basis. Thank you! Hopefully, this change will prevent confusion and unpleasant surprises for Django users in the future.\nHello everyone, I would like to work on this. But before that there are few important questions: There is a related setting called FILE_UPLOAD_DIRECTORY_PERMISSIONS. Its document says that This value mirrors the functionality and caveats of the FILE_UPLOAD_PERMISSIONS setting. Shall we also change its default from None to 0o644(Please suggest if something different should be provided for directories) and update its document as well? Since 2.2 pre-release branch is now in feature freeze state, Shall we move the change to 3.0 version? On a side note, some tests must be refactored for new values for both of these settings. I think that's alright.\nThat note is referring to that non-leaf directories are created using the process umask. (See ​`makedirs()` docs.) This is similar to FILE_UPLOAD_PERMISSIONS, when not using the temporary file upload handler. The underlying issue here is the inconsistency in file permissions, depending on the file size, when using the default settings that Django provides. There is no such inconsistency with directory permissions. As such changes should not be needed to FILE_UPLOAD_DIRECTORY_PERMISSIONS. (Any issues there would need to be addressed under a separate ticket.)\nReplying to Carlton Gibson: I see and understand the issue better now. Thanks for the clarification. I'll make the changes as you have suggested in your previous comment. Only question remaining is about introducing this change in 3.0 version. Shall we move it to 3.0 release?\nShall we move it to 3.0 release? Yes please.\n\n## Completed stages\n- **setup**: fail\n  - Script: `git clone https://github.com/django/django.git . && git checkout e7fd69d051eaa67cb17f172a39b57253e9cb831a && python -m pip install -e .`\n  - Stdout:\n    ```\n    fatal: destination path '.' already exists and is not an empty directory.\n    ```\n  - Stderr: (empty)\n- **solve**: fail\n\n## Context\n- failure_class: transient_infra\n- failure_signature: solve|transient_infra|api_transient|gemini|rate_limited\n",
    "command.stderr": "",
    "internal.thread_id": "solve",
    "graph.rankdir": "LR",
    "failure_class": "",
    "current_node": "extract_patch",
    "internal.retry_count.start": 1,
    "internal.run_id": "01KKV8599FCY4X1AKTGRSNJ6MP",
    "internal.retry_count.setup": 1,
    "failure_signature": "",
    "thread.start.current_node": "setup",
    "graph.goal": "Set default FILE_UPLOAD_PERMISSION to 0o644.\nDescription\n\t\nHello,\nAs far as I can see, the ​File Uploads documentation page does not mention any permission issues.\nWhat I would like to see is a warning that in absence of explicitly configured FILE_UPLOAD_PERMISSIONS, the permissions for a file uploaded to FileSystemStorage might not be consistent depending on whether a MemoryUploadedFile or a TemporaryUploadedFile was used for temporary storage of the uploaded data (which, with the default FILE_UPLOAD_HANDLERS, in turn depends on the uploaded data size).\nThe tempfile.NamedTemporaryFile + os.rename sequence causes the resulting file permissions to be 0o0600 on some systems (I experience it here on CentOS 7.4.1708 and Python 3.6.5). In all probability, the implementation of Python's built-in tempfile module explicitly sets such permissions for temporary files due to security considerations.\nI found mentions of this issue ​on GitHub, but did not manage to find any existing bug report in Django's bug tracker.\n\n\n\n## Additional Context\n\nI think you're talking about ef70af77ec53160d5ffa060c1bdf5ed93322d84f (#28540). I guess the question is whether or not that documentation should be duplicated elsewhere.\nThank you Tim, this is precisely what I was looking for! I can only see one issue with the current docs (if you excuse me for bothering you with such minor details). ​The documentation for the FILE_UPLOAD_PERMISSIONS setting reads: If this isn’t given or is None, you’ll get operating-system dependent behavior. On most platforms, temporary files will have a mode of 0o600, and files saved from memory will be saved using the system’s standard umask. As I would understand this text, only temporary files get a mode of 0o600. I would then ask myself: \"Why should I care about temporary files, they should be gone anyway after the file is uploaded?\" and skip setting FILE_UPLOAD_PERMISSIONS. What is important but is not properly conveyed to the user is that not only temporary files themselves, but also the actual files which end up in the media folder get permissions of 0o600. Currently a developer can only discover this either by careful reading of the Deployment checklist page (manage.py check --deploy does not seem to check FILE_UPLOAD_PERMISSIONS) or by hitting the inconsistent permissions accidentally (like I did). I propose to unify the docs for FILE_UPLOAD_PERMISSIONS on the Settings page and the Deployment checklist page like this: ​https://gist.github.com/earshinov/0340f741189a14d4fd10e3e902203ad6/revisions#diff-14151589d5408f8b64b7e0e580770f0e Pros: It makes more clear that one gets different permissions for the *uploaded* files. It makes the docs more unified and thus easier to synchronously change in the future if/when required. I recognize that my edits might seem too minor and insignificant to be worth the hassle of editing the docs, committing, re-publishing them etc., but still I hope you will find them useful enough to be integrated into the official docs.\nNow that I think about, maybe Django could provide # <Commentary about inconsistent permissions when this setting is omitted> FILE_UPLOAD_PERMISSINS=0o600 in the ​default project settings so that developers don't miss it? 600 seems a reasonable default, particularly because people would get 600 anyway (at least on some operating systems) when the TemporaryFileUploadHandler is engaged.\nSince this has come up again, I've suggested on django-developers (​https://groups.google.com/d/topic/django-developers/h9XbQAPv5-I/discussion) that we adjust the FILE_UPLOAD_PERMISSION default to 0o644 (This was the conclusion I eventually came to from the discussion on #28540.) Lets see what people say there.\nThus far, no great objections on the mailing list to adjusting the FILE_UPLOAD_PERMISSION default. Thus I'm going to rename this and Accept on that basis. A PR would need to: Adjust the default. Add a Breaking Change note to releases/2.2.txt (on the assumption we can get it in for then.) — This should include a set to None to restore previous behaviour' type comment. Adjust the references in the settings docs and deployment checklist. Make sure any other references are adjusted.\nReplying to Carlton Gibson: Thus far, no great objections on the mailing list to adjusting the FILE_UPLOAD_PERMISSION default. Thus I'm going to rename this and Accept on that basis. Thank you! Hopefully, this change will prevent confusion and unpleasant surprises for Django users in the future.\nHello everyone, I would like to work on this. But before that there are few important questions: There is a related setting called FILE_UPLOAD_DIRECTORY_PERMISSIONS. Its document says that This value mirrors the functionality and caveats of the FILE_UPLOAD_PERMISSIONS setting. Shall we also change its default from None to 0o644(Please suggest if something different should be provided for directories) and update its document as well? Since 2.2 pre-release branch is now in feature freeze state, Shall we move the change to 3.0 version? On a side note, some tests must be refactored for new values for both of these settings. I think that's alright.\nThat note is referring to that non-leaf directories are created using the process umask. (See ​`makedirs()` docs.) This is similar to FILE_UPLOAD_PERMISSIONS, when not using the temporary file upload handler. The underlying issue here is the inconsistency in file permissions, depending on the file size, when using the default settings that Django provides. There is no such inconsistency with directory permissions. As such changes should not be needed to FILE_UPLOAD_DIRECTORY_PERMISSIONS. (Any issues there would need to be addressed under a separate ticket.)\nReplying to Carlton Gibson: I see and understand the issue better now. Thanks for the clarification. I'll make the changes as you have suggested in your previous comment. Only question remaining is about introducing this change in 3.0 version. Shall we move it to 3.0 release?\nShall we move it to 3.0 release? Yes please.",
    "internal.node_visit_count": 1,
    "outcome": "success",
    "command.output": "",
    "thread.setup.current_node": "solve",
    "internal.fidelity": "compact",
    "internal.retry_count.solve": 4,
    "thread.solve.current_node": "extract_patch"
  },
  "logs": [],
  "node_outcomes": {
    "extract_patch": {
      "status": "success",
      "context_updates": {
        "command.output": "",
        "command.stderr": ""
      },
      "notes": "Script completed: git diff",
      "duration_ms": 89
    },
    "solve": {
      "status": "fail",
      "failure": {
        "message": "LLM error: Rate limited by gemini: You exceeded your current quota, please check your plan and billing details. For more information on this error, head to: https://ai.google.dev/gemini-api/docs/rate-limits. To monitor your current usage, head to: https://ai.dev/rate-limit. \n* Quota exceeded for metric: generativelanguage.googleapis.com/generate_requests_per_model, limit: 25, model: gemini-3.1-pro\nPlease retry in 16.726286228s.",
        "failure_class": "transient_infra",
        "failure_signature": "api_transient|gemini|rate_limited"
      },
      "duration_ms": 90213
    },
    "setup": {
      "status": "fail",
      "context_updates": {
        "command.stderr": "",
        "command.output": "fatal: destination path '.' already exists and is not an empty directory.\n"
      },
      "failure": {
        "message": "Script failed with exit code: 128\n\n## stdout\nfatal: destination path '.' already exists and is not an empty directory.\n",
        "failure_class": "deterministic"
      },
      "duration_ms": 86
    },
    "start": {
      "status": "success",
      "duration_ms": 0
    }
  },
  "next_node_id": "exit",
  "loop_failure_signatures": {
    "setup|deterministic|script failed with exit code: <n> ## stdout fatal: destination path '.' already exists and is not an empty directory.": 1
  },
  "node_visits": {
    "start": 1,
    "solve": 1,
    "extract_patch": 1,
    "setup": 1
  }
}