[ruby-core:81300] [Ruby trunk Feature#13568] File#path for O_TMPFILE fds are unmeaning

Issue #13568 has been updated by shyouhei (Shyouhei Urabe).


At the meeting we discussed the use case of File#path and we thought there are 2 kinds:

- Pass it to open()
- Pass it to printf() or variant

We considered both and concluded it is best to return a nonexistent path, not nil.

Hanmac (Hans Mackowiak) wrote:
> 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.

Trying to open nil is like this:

```
irb(main):001:0> open(nil)
TypeError: no implicit conversion of nil into String
        from (irb):1:in `open'
```

OTOH trying to open nonexistent path is:

```
irb(main):001:0> open("/tmp/#165106976 (deleted)")
Errno::ENOENT: No such file or directory @ rb_sysopen - /tmp/#165106976 (deleted)
        from (irb):1:in `initialize'
        from (irb):1:in `open'
```

Do you think nil is better?  I think nonexistent path is far more descriptive.

> 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

Yes.  We found that quite generally speaking, it is a bad idea to pass a file's path into open.  Because such thing is not guaranteed to exist.  I proposed prohibiting File#path but that was rejected; because path is not only meant to be passed to open but also for inspection.  When passing to printf or logger or something like that, something other than nil is desirable.  I filed  #13576 to focus on "file's path passed to open" situation.

> 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

(Out of curiousity) are there such ways?  What do you have in mind?

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

* 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:[e-mail]?subject=unsubscribe>
<http://lists.ruby-lang.org/cgi-bin/mailman/options/ruby-core>