Issue #13568 has been updated by Hanmac (Hans Mackowiak).


i think returing an unexisting path whould be way problematic if it isnt checked if it exist.
other functions might depend on it. 
and trying to open "/tmp/#165106976 (deleted)" in (read)/writing mode might result in unexpected results.

can it later checked if a file was open with o_TMPFILE?
if not, when with unexisting path, you can't know if the file can be reopen.
that might be related to #13576

i would prefer it to return nil.

PS: there might be ways to get the filesystem without using that File#path method, so return nil should be okay

----------------------------------------
Feature #13568: File#path for O_TMPFILE fds are unmeaning
https://bugs.ruby-lang.org/issues/13568#change-64946

* Author: sorah (Sorah Fukumori)
* Status: Assigned
* Priority: Normal
* Assignee: sorah (Sorah Fukumori)
* Target version: 
----------------------------------------
By using File::TMPFILE (O_TMPFILE) allows us to create a file without directory entries.

While open(2) with O_TMPFILE don't create a file without directory entries, it still requires a directory name to determine a file system to create a file.

Current Ruby implementation holds such directory names in fptr->pathv and retrievable via File#path.
But such paths are useless and may raise errors. For example, some code [1] checks File#path availability then when available, it attempts to use the path to open a file in different fd, finally raises Errno::EISDIR.

This patch changes File#path (fptr->pathv) not to return String if a fd is opened with O_TMPFILE.

[1]: https://github.com/aws/aws-sdk-ruby/blob/v2.9.17/aws-sdk-core/lib/aws-sdk-core/checksums.rb#L15

---Files--------------------------------
tmpfile-path.patch (1.96 KB)


-- 
https://bugs.ruby-lang.org/

Unsubscribe: <mailto:ruby-core-request / ruby-lang.org?subject=unsubscribe>
<http://lists.ruby-lang.org/cgi-bin/mailman/options/ruby-core>