Feature #4057: FileUtils.copy with FIFOs and Special Devices

• Status: Rejected
• Assignee: mame (Yusuke Endoh)
• Target version: -

[runpaint (Run Paint Run Run)]

=begin
In http://redmine.ruby-lang.org/repositories/diff/ruby-19?rev=6747 support for copying FIFOs and special devices was added to FileUtils.copy, and the same code exists in trunk. It relies on the existence of File.mknod and File.mkfifo. According to git's "pickaxe", those methods have never existed. Various patches to add this functionality have been sent to ruby-core, but in http://www.ruby-forum.com/topic/144168 matz rejected the idea. So, presumably, either these checks should be removed from FileUtils such that it raises an exception when a special device is encountered, or we should replace them with calls to the mknod/mkfifo commands. For me, the following just hangs:

run@paint:~$ mkfifo fifo
run@paint:~$ ruby -rfileutils -e 'FileUtils.copy("fifo", "lifo")'
=end

[naruse (Yui NARUSE)]

• Tracker changed from Bug to Feature

That code seems a preparation of feature extension about FIFOs.

[akr (Akira Tanaka)]

• Description updated (diff)

I feel following hang is bad behavior.

% mkfifo p
% ruby -v -rfileutils -e 'FileUtils.copy "p", "p2"'
ruby 2.0.0dev (2012-03-16 trunk 35049) [x86_64-linux]
...hang...

However cp also hangs.

% cp p p2
..hang...

cp -a don't hang though.

[mame (Yusuke Endoh)]

• Assignee set to mame (Yusuke Endoh)
• Status changed from Open to Assigned

[mame (Yusuke Endoh)]

• Status changed from Assigned to Rejected

Hello,

Runpaint, I think you meant FileUtils.copy_entry.

$ mkfifo fifo
$ ruby -rfileutils -e 'FileUtils.copy_entry("fifo", "lifo")'
...:in `copy': cannot handle FIFO (RuntimeError)

So,
presumably, either these checks should be removed from FileUtils such that
it raises an exception when a special device is encountered, or we should
replace them with calls to the mknod/mkfifo commands.

I object to replacing it.
Matz said "mknod and mkfifo are not ubiquitous". The same is true
for the commands.

I also object to removing the check.
I don't think there are any actual problems in the current behavior.
Though I don't recommend strongly, a user can change the behavior by
just defining File.mkfifo method.
Removing the check brings disadvantage but no advantage, I think.

So, I close this ticket as Rejected.
If you know any actual problem about the current behavior, please
reopen this ticket.

Thanks,

--
Yusuke Endoh [e-mail]