[#63592] [ruby-trunk - Bug #10009] IO operation is 10x slower in multi-thread environment — normalperson@...
Issue #10009 has been updated by Eric Wong.
3 messages
2014/07/08
[#63682] [ruby-trunk - Feature #10030] [PATCH] reduce rb_iseq_struct to 296 bytes — ko1@...
Issue #10030 has been updated by Koichi Sasada.
3 messages
2014/07/13
[#63703] [ruby-trunk - Feature #10030] [PATCH] reduce rb_iseq_struct to 296 bytes — ko1@...
Issue #10030 has been updated by Koichi Sasada.
3 messages
2014/07/14
[#63743] [ruby-trunk - Bug #10037] Since r46798 on Solaris, "[BUG] rb_vm_get_cref: unreachable" during make — ngotogenome@...
Issue #10037 has been updated by Naohisa Goto.
3 messages
2014/07/15
[#64136] Ruby 2.1.2 (and 2.1.1 and probably others) assumes a libffi with 3 version numbers in extconf.rb — "Jeffrey 'jf' Lim" <jfs.world@...>
As per subject.
4 messages
2014/07/31
[#64138] Re: Ruby 2.1.2 (and 2.1.1 and probably others) assumes a libffi with 3 version numbers in extconf.rb
— "Jeffrey 'jf' Lim" <jfs.world@...>
2014/07/31
On Thu, Jul 31, 2014 at 6:03 PM, Jeffrey 'jf' Lim <jfs.world@gmail.com>
[ruby-core:63866] [ruby-trunk - Bug #10067] File.file? misleading semantics & documentation for symbolic links
From:
robe@...
Date:
2014-07-19 10:14:37 UTC
List:
ruby-core #63866
Issue #10067 has been updated by Michael Renner.
Nobuyoshi Nakada wrote:
> Citing from [POSIX manpage test(1)](http://www.unix.com/man-page/POSIX/1/test/)
> > With the exception of the `-h pathname` and `-L pathname` primaries,
> > if a `pathname` argument is a symbolic link, `test` shall evaluate the
> > expression by resolving the symbolic link and using the file
> > referenced by the link.
Oh my, just double-checked, Python and Perl have implemented the same behaviour as test(1), along with Ruby.
The big difference being the wording of the documentation. The test man page explicitly states:
> True if pathname **resolves to** an existing directory entry for a [..]
as well as the paragraph you quoted.
I guess clarifying that in the File documentation is warranted as well as pointing out that people are strongly advised to use lstat if they want consistent behaviour.
I personally would go as far and ditch the test(1) semantics and stick to querying lstat() by default, but that's just me and will probably break lots of things ;)
----------------------------------------
Bug #10067: File.file? misleading semantics & documentation for symbolic links
https://bugs.ruby-lang.org/issues/10067#change-47891
* Author: Michael Renner
* Status: Open
* Priority: Normal
* Assignee: Zachary Scott
* Category: doc
* Target version: current: 2.2.0
* ruby -v: ruby 1.9.3p194 (2012-04-20 revision 35410) [x86_64-linux]
* Backport: 2.0.0: UNKNOWN, 2.1: UNKNOWN
----------------------------------------
The documentation for ``File.file?`` states:
"Returns true if the named file exists and is a regular file."
When trying that out I get the following results:
~~~
% /usr/bin/stat link
File: `link' -> `file'
Size: 4 Blocks: 0 IO Block: 4096 symbolic link
Device: 16h/22d Inode: 2804357 Links: 1
Access: (0777/lrwxrwxrwx) Uid: ( 1000/ robe) Gid: ( 1000/ robe)
Access: 2014-07-19 01:01:51.514979670 +0200
Modify: 2014-07-19 01:01:50.799975936 +0200
Change: 2014-07-19 01:01:50.799975936 +0200
Birth: -
% ruby -e "puts File.file?('link')"
false
% ruby -e "puts File.symlink?('link')"
true
% touch file
% ruby -e "puts File.file?('link')"
true
% ruby -e "puts File.symlink?('link')"
true
%
~~~
which is entirely not what one would expect.
You need to decide if the ``File`` ``?``-methods offer [stat](http://pubs.opengroup.org/onlinepubs/009695399/functions/stat.html) _OR_ [lstat](http://pubs.opengroup.org/onlinepubs/009695399/functions/lstat.html) semantic, change it and document it accordingly.
The current documentation and implementation behavior is especially confusing since the [POSIX standard](http://pubs.opengroup.org/onlinepubs/009695399/basedefs/sys/stat.h.html) states that the type of a file can be either a regular file _OR_ a symlink, not both at the same time.
--
https://bugs.ruby-lang.org/