[issue26362] Approved API for creating a temporary file path

Irit Katriel added the comment: > So no, while unresolved, this bug report should not be closed. This is not a bug report, it's a feature request, and there is enough resistance in the discussion to reject it (according to the Status Quo Wins a Stalemate principle). What may be unresolved

[issue26362] Approved API for creating a temporary file path

Serhiy Storchaka added the comment: This function would increase security risks. Even if it will be documented as "This function is only purposed to generate file paths which looks similar to paths of temporary files generated by other functions in this module, but should not be used for

[issue26362] Approved API for creating a temporary file path

Eryk Sun added the comment: > So no, while unresolved, this bug report should not be closed. The implied question was whether you or the core devs on the nosy list, upon further consideration, wanted to resolve the issue by rejecting the request, but it had simply been forgotten about for 4

[issue26362] Approved API for creating a temporary file path

Ben Finney added the comment: > tempfile.mktemp() still exists and works without raising a deprecation > warning. Of course it's still marked as deprecated in the docs. Right. So, the issue is not resolved: Functionality to create a temporary file path is maintained in the standard library

[issue26362] Approved API for creating a temporary file path

Eryk Sun added the comment: > The proposal in this issue is to have a public standard library API, > which I'm calling ‘tempfile.makepath’, It's a few years later, and tempfile.mktemp() still exists and works without raising a deprecation warning. Of course it's still marked as deprecated in

[issue26362] Approved API for creating a temporary file path

Eryk Sun added the comment: > the lack of Windows' os.rename() atomicity rename/replace is two system calls: NtOpenFile to get a handle for the source file and NtSetInformationFile to rename it. The difference is only that replace() sets the ReplaceIfExists field in the FileRenameInformation.

[issue26362] Approved API for creating a temporary file path

Ben Finney added the comment: On 01-May-2017, Serhiy Storchaka wrote: > tempfile.mktemp() is not much more useful that just a function that > generates some names which unlikely matches the names of existing > files the directory. Yes. That is already useful enough to be in the standard

[issue26362] Approved API for creating a temporary file path

Serhiy Storchaka added the comment: > temp_name = tempfile.mktemp(dir=".") > os.link("a", temp_name) There is a race condition between generating file name and using it. tempfile.mktemp() is not much more useful that just a function that generates some names which unlikely matches the names

[issue26362] Approved API for creating a temporary file path

Tim Chase added the comment: I do have a workaround thanks to Gregory Ewing https://mail.python.org/pipermail/python-list/2017-May/721649.html which suffices for my particular use-case (generating a link to a file with a unique filename). As my use-case is predominantly for *nix environments,

[issue26362] Approved API for creating a temporary file path

Eryk Sun added the comment: For Windows, use os.replace instead of os.rename, which will replace the destination file if it exists. However, a request to replace an existing file will be denied access if the file is currently open. Unlinking an open file isn't allowed, even if it's open with

[issue26362] Approved API for creating a temporary file path

R. David Murray added the comment: Yes, and I'm saying his example doesn't work on Windows (on windows, it does not accomplish his goal). So I'm not sure it is a use case appropriate for the standard library. I'm not saying it definitely isn't, I'm just raising a doubt. --

[issue26362] Approved API for creating a temporary file path

Ben Finney added the comment: On 01-May-2017, R. David Murray wrote: > You are depending on a non-portable feature of os.rename there What's the non-portable dependency? If you mean the expectation that ‘os.rename’ will be atomic on success: the documentation promises “If successful, the

[issue26362] Approved API for creating a temporary file path

R. David Murray added the comment: You are depending on a non-portable feature of os.rename there, so I'm not convinced this makes a good use case for the Python stdlib. -- nosy: +r.david.murray ___ Python tracker

[issue26362] Approved API for creating a temporary file path

Tim Chase added the comment: As requested by Ben Finney[1], adding my use-case here. I'm attempting to make a hard-link from "a" to "b", but if "b" exists, os.link() will fail with an EEXISTS. I don't want to do os.unlink("b") # power-outage here means "b" is gone os.link("a", "b") I

[issue26362] Approved API for creating a temporary file path

Ben Finney added the comment: Serhiy Storchaka > mktemp is deprecated, and I think we will get rid of it when 2.7 will be out > of use. That's fine. This is not a request to retain ‘tempfile.mktemp’. I confused matters in my initial message, so your confusion is understandable on this

[issue26362] Approved API for creating a temporary file path

Serhiy Storchaka added the comment: mktemp is deprecated, and I think we will get rid of it when 2.7 will be out of use. Do you want to add new deprecated from the start function? > As far as appropriate location -- where else would you put it? May be in third-party module on PyPI? It doesn't

[issue26362] Approved API for creating a temporary file path

Ethan Furman added the comment: I don't see the problem. Every Python platform that has `mktemp` has an implementation to generate the names, and that implementation can become the public face instead of `mktemp`. So no more of a burden than `mktemp` is; likewise for the "cognitive burden".

[issue26362] Approved API for creating a temporary file path

Serhiy Storchaka added the comment: I see a problem. tempfile._get_candidate_names is implementation detail, and exposing it adds a burden for maintainers. It also adds cognitive burden for users of the tempfile module. And the idea itself looks doubtful and contradictory with the good

[issue26362] Approved API for creating a temporary file path

Ethan Furman added the comment: > The request is for a “get the next path generated by a > ‘tempfile._get_candidate_names’ generator”, with an approved and > documented public API. I don't see any problem with this. Patches welcome. -- stage: -> needs patch

[issue26362] Approved API for creating a temporary file path

Ben Finney added the comment: > I have read the thread on Python-list Thank you, and thanks for linking to that discussion. > and still don't understand the purpose of your idea. The purpose is to get a public API for making temporary filesystem paths with the same properties as are produced

[issue26362] Approved API for creating a temporary file path

Serhiy Storchaka added the comment: I have read the thread on Python-list (http://comments.gmane.org/gmane.comp.python.general/789339) and still don't understand the purpose of your idea. If you need unique filesystem paths without any access to real filesystem, you can use simple counter.

[issue26362] Approved API for creating a temporary file path

Ben Finney added the comment: An example:: import io import tempfile names = tempfile._get_candidate_names() def test_frobnicates_configured_spungfile(): """ ‘foo’ should frobnicate the configured spungfile. """ fake_file_path =

[issue26362] Approved API for creating a temporary file path

Ben Finney added the comment: It has been pointed out that `tempfile.mktemp` does in fact access the filesystem, to query whether the entry exists. So this request would be best met by exposing a simple “get a new return value from the `tempfile._RandomNameSequence` instance” function.

[issue26362] Approved API for creating a temporary file path

Changes by Ethan Furman : -- nosy: +ethan.furman ___ Python tracker ___ ___

[issue26362] Approved API for creating a temporary file path

New submission from Ben Finney: The security issues of `tempfile.mktemp` are clear when the return value is used to create a filesystem entry. The documentation and docstrings (and even some comments on past issues) are correct o deprecate its use for that purpose. The function has a use