[ 
https://issues.apache.org/jira/browse/TINKERPOP-1493?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15667220#comment-15667220
 ] 

ASF GitHub Bot commented on TINKERPOP-1493:
-------------------------------------------

Github user pauljackson commented on the issue:

    https://github.com/apache/tinkerpop/pull/457
  
    Looking at the Hadoop code gives no direct clue (to me), but it does seem 
to indicate that you are not using the 2.7.2 version, which might explain the 
inconsistent results. Maybe your local maven repo has the wrong version?
    
    The stack trace ends with:
    Caused by: java.io.IOException: Mkdirs failed to create 
/usr/src/tinkerpop/spark-gremlin/target/test-case-data/SparkHadoopGraphProvider/graph-provider-data/~reducing/_temporary/0/_temporary/attempt_201611051613_15726_r_000000_0
 (exists=false, cwd=file:/usr/src/tinkerpop/spark-gremlin)
        at 
org.apache.hadoop.fs.ChecksumFileSystem.create(ChecksumFileSystem.java:450)
        at 
org.apache.hadoop.fs.ChecksumFileSystem.create(ChecksumFileSystem.java:435)
    
    I grabbed the related source from for version 2.7.2 from here: 
https://archive.apache.org/dist/hadoop/core/hadoop-2.7.2/
    
https://archive.apache.org/dist/hadoop/core/hadoop-2.7.2/hadoop-2.7.2-src.tar.gz
    
hadoop-2.7.2-src/hadoop-common-project/hadoop-common/src/main/java/org/apache/hadoop/fs/ChecksumFileSystem.java
    
    The related code does have a call to create() on line 435 but the exception 
is thrown on line 449:
      @Override
      public FSDataOutputStream create(Path f, FsPermission permission,
          boolean overwrite, int bufferSize, short replication, long blockSize,
          Progressable progress) throws IOException {
        return create(f, permission, overwrite, true, bufferSize, // 435
            replication, blockSize, progress);
      }
    
      private FSDataOutputStream create(Path f, FsPermission permission,
          boolean overwrite, boolean createParent, int bufferSize,
          short replication, long blockSize,
          Progressable progress) throws IOException {
        Path parent = f.getParent();
        if (parent != null) {
          if (!createParent && !exists(parent)) {
            throw new FileNotFoundException("Parent directory doesn't exist: "
                + parent);
          } else if (!mkdirs(parent)) {
            throw new IOException("Mkdirs failed to create " + parent //449
                + " (exists=" + exists(parent) + ", cwd=" + 
getWorkingDirectory() // 450
                + ")");
          }
        }
    
    
    
    From: stephen mallette [mailto:notificati...@github.com]
    Sent: Tuesday, November 15, 2016 8:24 AM
    To: apache/tinkerpop
    Cc: Paul A. Jackson; Author
    Subject: Re: [apache/tinkerpop] TINKERPOP-1493 Groovy project doesn't build 
on Windows (#457)
    
    
    The stack trace is pasted above.
    
    —
    You are receiving this because you authored the thread.
    Reply to this email directly, view it on 
GitHub<https://github.com/apache/tinkerpop/pull/457#issuecomment-260639858>, or 
mute the 
thread<https://github.com/notifications/unsubscribe-auth/AAUcSDXZOcPvgxhDo673VXzssRyskI47ks5q-bJdgaJpZM4KVbcO>.
    
    ________________________________
    



> Groovy project doesn't build on Windows
> ---------------------------------------
>
>                 Key: TINKERPOP-1493
>                 URL: https://issues.apache.org/jira/browse/TINKERPOP-1493
>             Project: TinkerPop
>          Issue Type: Bug
>          Components: groovy
>    Affects Versions: 3.2.2
>            Reporter: Paul Jackson
>            Assignee: Jason Plurad
>            Priority: Minor
>
> Builds on Windows fail for two reasons. First the line to create extTestDir 
> is creating a path consisting of two full paths concatenated together. The 
> second drive letter is seen as an illegal character:
> {code}private static final File extTestDir = new 
> File(System.getProperty("user.dir"), 
> TestHelper.makeTestDataDirectory(DependencyGrabberTest.class));{code}
> Second, when it comes time to delete the directory it is locked. This is 
> because some instances of JarFile are created on it but not closed.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

Reply via email to