Details

    • Type: Bug Bug
    • Status: Resolved Resolved
    • Priority: Major Major
    • Resolution: Fixed
    • Affects Version/s: JRuby 1.3, JRuby 1.3.1
    • Fix Version/s: None
    • Component/s: None
    • Labels:
      None
    • Environment:
      Failing in both 1.3 + 1.3.1
    • Number of attachments :
      0

      Description

      The following works in ruby 1.8.6 but is failing:

      mkfifo my_pipe
      jruby -e "open('my_pipe', 'w+')"
      -e:1:in `open': Illegal seek (IOError)
      from -e:1

        Activity

        Hide
        Gerald Boersma added a comment -

        Is this a regression of defect #3071?

        Show
        Gerald Boersma added a comment - Is this a regression of defect #3071?
        Hide
        Gerald Boersma added a comment -

        Looks like it is not related to #3071, although the solution may be related. If the file is a named pipe, mark it as not seekable. Just need a way to determine under Java whether the file is a named pipe or not.

        Show
        Gerald Boersma added a comment - Looks like it is not related to #3071, although the solution may be related. If the file is a named pipe, mark it as not seekable. Just need a way to determine under Java whether the file is a named pipe or not.
        Hide
        Charles Oliver Nutter added a comment -

        Here's a fix for this that I don't particularly like...basically it just catches the internal Java IOException, checks if it's "Illegal seek" and ignores it. This doesn't worry me too much, but it would obviously be better if we could somehow determine a file is a pipe (or a device...there's another bug in here somewhere about opening devices and getting the same error).

        diff --git a/src/org/jruby/util/io/ChannelDescriptor.java b/src/org/jruby/util/io/ChannelDescriptor.java
        index 05d69a2..cc1b893 100644
        --- a/src/org/jruby/util/io/ChannelDescriptor.java
        +++ b/src/org/jruby/util/io/ChannelDescriptor.java
        @@ -671,7 +671,16 @@ public class ChannelDescriptor {
                         }
                     }
         
        -            if (flags.isTruncate()) file.setLength(0L);
        +            try {
        +                if (flags.isTruncate()) file.setLength(0L);
        +            } catch (IOException ioe) {
        +                if (ioe.getMessage().equals("Illegal seek")) {
        +                    // it's not a seekable file, which means it's probably a
        +                    // device or pipe. Ignore. (Is this ok?)
        +                } else {
        +                    throw ioe;
        +                }
        +            }
         
                     // TODO: append should set the FD to end, no? But there is no seek(int) in libc!
                     //if (modes.isAppendable()) seek(0, Stream.SEEK_END);
        

        Suggestions welcome.

        Show
        Charles Oliver Nutter added a comment - Here's a fix for this that I don't particularly like...basically it just catches the internal Java IOException, checks if it's "Illegal seek" and ignores it. This doesn't worry me too much, but it would obviously be better if we could somehow determine a file is a pipe (or a device...there's another bug in here somewhere about opening devices and getting the same error). diff --git a/src/org/jruby/util/io/ChannelDescriptor.java b/src/org/jruby/util/io/ChannelDescriptor.java index 05d69a2..cc1b893 100644 --- a/src/org/jruby/util/io/ChannelDescriptor.java +++ b/src/org/jruby/util/io/ChannelDescriptor.java @@ -671,7 +671,16 @@ public class ChannelDescriptor { } } - if (flags.isTruncate()) file.setLength(0L); + try { + if (flags.isTruncate()) file.setLength(0L); + } catch (IOException ioe) { + if (ioe.getMessage().equals("Illegal seek")) { + // it's not a seekable file, which means it's probably a + // device or pipe. Ignore. (Is this ok?) + } else { + throw ioe; + } + } // TODO: append should set the FD to end, no? But there is no seek(int) in libc! //if (modes.isAppendable()) seek(0, Stream.SEEK_END); Suggestions welcome.
        Hide
        Kevin Menard added a comment -

        I think the error message on this has now changed to "not opened for writing", but it's still an issue. Is there a workaround for working with pipes that others have been using? I'd imagine not, but since this patch has been attached here for 2.5 years, I figured I'd check.

        Show
        Kevin Menard added a comment - I think the error message on this has now changed to "not opened for writing", but it's still an issue. Is there a workaround for working with pipes that others have been using? I'd imagine not, but since this patch has been attached here for 2.5 years, I figured I'd check.
        Hide
        Hiro Asari added a comment -

        Kevin,

        I am not seeing the error message you describe.

        Charlie's patch above was applied to the master (01fa54f7) and the 1.6 branch (69bd6c5d) on January 2, 2012. It should be in 1.6.6.

        The particular test case for which this ticket was opened no longer fails the way it is described here.

        Which version of JRuby are you running?

        Show
        Hiro Asari added a comment - Kevin, I am not seeing the error message you describe. Charlie's patch above was applied to the master (01fa54f7) and the 1.6 branch (69bd6c5d) on January 2, 2012. It should be in 1.6.6. The particular test case for which this ticket was opened no longer fails the way it is described here. Which version of JRuby are you running?
        Hide
        Charles Oliver Nutter added a comment -

        Calling this fixed, since there was a fix put in place and no follow-up.

        Show
        Charles Oliver Nutter added a comment - Calling this fixed, since there was a fix put in place and no follow-up.

          People

          • Assignee:
            Charles Oliver Nutter
            Reporter:
            Dr Nic Williams
          • Votes:
            0 Vote for this issue
            Watchers:
            1 Start watching this issue

            Dates

            • Created:
              Updated:
              Resolved: