prefixAll  string
}

// disconnectReader will ensure that no reads can take place on
// the upstream reader after close has been called.
type disconnectReader struct {
	r  io.Reader
	mu sync.Mutex
}

func (d *disconnectReader) Read(p []byte) (n int, err error) {
	d.mu.Lock()
	defer d.mu.Unlock()
	if d.r != nil {
		return d.r.Read(p)
	}
	return 0, errors.New("reader closed")
}

/**
 * This class will allow a Java program to read and write data to Named
 * Pipes and Transact NamedPipes.
 *
 * <p>
 * There are three Win32 function calls provided by the Windows SDK
 * that are important in the context of using jCIFS. They are:
 *
 * <ul>
 * <li><code>CallNamedPipe</code> A message-type pipe call that opens,
 * writes to, reads from, and closes the pipe in a single operation.

     * <p>A typical usage is to invoke this method for all dependencies having a
     * {@link DependencyScope#TEST TEST} or {@link DependencyScope#TEST_ONLY TEST_ONLY}
     * {@linkplain Dependency#getScope() scope}. An {@code --add-reads} option may need
     * to be generated for compiling and running the test classes that use such dependencies.</p>
     *
     * @param dependency path to the dependency for which to get the module name

     * look at table entries if it is 0.
     *
     * - All (synchronized) write operations should write to the "count" field after structurally
     * changing any bin. The operations must not take any action that could even momentarily
     * cause a concurrent read operation to see inconsistent data. This is made easier by the

			}
			r.err = err
			return err
		}
	}
}

// readN will return all the requested number of entries in order
// or all if n < 0.
// Will return io.EOF if end of stream is reached.
// If requesting 0 objects nil error will always be returned regardless of at end of stream.
// Use peek to determine if at end of stream.

    // The stream reports no bytes... importantly, it doesn't read the byte at index 5 when it
    // should be reading the byte at index 10.
    // We could use a custom InputStream instead to make the read start at index 10, but since this
    // is a racy situation anyway, this behavior seems reasonable.
    assertEquals(-1, in.read());
  }

  private static class AppendableByteSource extends ByteSource {

        // Decode to new instance (decode reads 36 bytes, encode writes 40)
        FileBasicInfo decoded = new FileBasicInfo();
        int decodedBytes = decoded.decode(buffer, 0, 36);

        // Verify encoding/decoding
        assertEquals(40, encodedBytes); // encode writes 40 bytes (includes padding)
        assertEquals(36, decodedBytes); // decode reads 36 bytes (no padding)

        }
    }

    /**
     * Test that resource content is properly read using readAllBytes.
     * Verifies that the new implementation correctly reads entire resource content.
     */
    @Test
    public void testResourceReading_readAllBytesCorrectness() throws Exception {
        // Read using the new method (readAllBytes)
        String contentNew;

        return Smb2Constants.SMB2_HEADER_LENGTH;
    }

    /**
     * Reads the SMB2 header from the wire format.
     *
     * @param buffer the buffer to read from
     * @param bufferIndex the starting position in the buffer
     * @return number of bytes read
     */
    protected int readHeaderWireFormat(final byte[] buffer, int bufferIndex) {

}

// NewReader returns a new Reader that wraps src and computes
// MD5 checksum of everything it reads as ETag.
//
// It also computes the SHA256 checksum of everything it reads
// if sha256Hex is not the empty string.
//
// If size resp. actualSize is unknown at the time of calling
// NewReader then it should be set to -1.