Closed michael-conway closed 10 years ago
ran unit test successfully
package org.irods.jargon.core.unittest.functionaltest;
import java.io.File;
import java.util.Properties;
import junit.framework.Assert;
import org.irods.jargon.core.connection.IRODSAccount;
import org.irods.jargon.core.protovalues.FilePermissionEnum;
import org.irods.jargon.core.pub.CollectionAO;
import org.irods.jargon.core.pub.DataTransferOperations;
import org.irods.jargon.core.pub.IRODSAccessObjectFactory;
import org.irods.jargon.core.pub.IRODSFileSystem;
import org.irods.jargon.core.pub.MountedCollectionAO;
import org.irods.jargon.core.pub.io.IRODSFile;
import org.irods.jargon.core.pub.io.IRODSFileFactory;
import org.irods.jargon.testutils.IRODSTestSetupUtilities;
import org.irods.jargon.testutils.TestingPropertiesHelper;
import org.irods.jargon.testutils.filemanip.FileGenerator;
import org.irods.jargon.testutils.filemanip.ScratchFileUtils;
import org.junit.After;
import org.junit.AfterClass;
import org.junit.Before;
import org.junit.BeforeClass;
import org.junit.Test;
/**
* Test Case for Bug #38 https://github.com/DICE-UNC/jargon/issues/38 Data Not
* Found doing idrop desktop download from file in public via softlink
*
* @author Mike Conway - DICE
*
*/
public class TestBug38GetFileFromSoftLinkedPublicCollection {
private static Properties testingProperties = new Properties();
private static TestingPropertiesHelper testingPropertiesHelper = new TestingPropertiesHelper();
private static ScratchFileUtils scratchFileUtils = null;
public static final String IRODS_TEST_SUBDIR_PATH = "TestBug38GetFileFromSoftLinkedPublicCollection";
private static IRODSTestSetupUtilities irodsTestSetupUtilities = null;
private static IRODSFileSystem irodsFileSystem;
@BeforeClass
public static void setUpBeforeClass() throws Exception {
TestingPropertiesHelper testingPropertiesLoader = new TestingPropertiesHelper();
testingProperties = testingPropertiesLoader.getTestProperties();
scratchFileUtils = new ScratchFileUtils(testingProperties);
irodsFileSystem = IRODSFileSystem.instance();
scratchFileUtils
.clearAndReinitializeScratchDirectory(IRODS_TEST_SUBDIR_PATH);
irodsTestSetupUtilities = new IRODSTestSetupUtilities();
irodsTestSetupUtilities.initializeIrodsScratchDirectory();
irodsTestSetupUtilities
.initializeDirectoryForTest(IRODS_TEST_SUBDIR_PATH);
}
@AfterClass
public static void tearDownAfterClass() throws Exception {
}
@Before
public void setUp() throws Exception {
}
@After
public void tearDown() throws Exception {
irodsFileSystem.closeAndEatExceptions();
}
@Test
public void testBugCase() throws Exception {
// make a dir as test1
String testDir = "softlinkme";
String softLinkSubdir = "softlinkhere";
String localRetrievedDir = "localRetrievedDir";
String targetIrodsCollection = testingPropertiesHelper
.buildIRODSCollectionAbsolutePathFromTestProperties(
testingProperties, IRODS_TEST_SUBDIR_PATH);
IRODSAccount irodsAccount = testingPropertiesHelper
.buildIRODSAccountFromTestProperties(testingProperties);
IRODSAccessObjectFactory accessObjectFactory = irodsFileSystem
.getIRODSAccessObjectFactory();
CollectionAO collectionAO = accessObjectFactory
.getCollectionAO(irodsAccount);
IRODSFile irodsFile = collectionAO
.instanceIRODSFileForCollectionPath(targetIrodsCollection + "/"
+ testDir);
irodsFile.mkdirs();
// make some subfiles
String subfile1 = "subfile1.txt";
String subfile2 = "subfile2.txt";
// use a local file and put it
String absPath = scratchFileUtils
.createAndReturnAbsoluteScratchPath(IRODS_TEST_SUBDIR_PATH);
String localFileName = FileGenerator
.generateFileOfFixedLengthGivenName(absPath, subfile1, 10);
String localFileName2 = FileGenerator
.generateFileOfFixedLengthGivenName(absPath, subfile2, 100);
File localFile1 = new File(localFileName);
File localFile2 = new File(localFileName2);
DataTransferOperations dataTransferOperations = irodsFileSystem
.getIRODSAccessObjectFactory().getDataTransferOperations(
irodsAccount);
IRODSFileFactory fileFactory = irodsFileSystem
.getIRODSFileFactory(irodsAccount);
IRODSFile subFile = fileFactory.instanceIRODSFile(
irodsFile.getAbsolutePath(), subfile1);
IRODSFile subFile2 = fileFactory.instanceIRODSFile(
irodsFile.getAbsolutePath(), subfile2);
// TransferControlBlock tcb =
dataTransferOperations.putOperation(localFile1, subFile, null, null);
subFile = fileFactory.instanceIRODSFile(irodsFile.getAbsolutePath(),
subfile2);
dataTransferOperations.putOperation(localFile2, subFile2, null, null);
// now make a soft link under public
String publicDir = "/" + irodsAccount.getZone() + "/home/public";
IRODSFile publicFile = fileFactory.instanceIRODSFile(publicDir);
if (!publicFile.exists()) {
publicFile.mkdirs();
collectionAO.setAccessPermission(irodsAccount.getZone(), publicDir,
"public", true, FilePermissionEnum.READ);
}
// do an initial unmount
MountedCollectionAO mountedCollectionAO = irodsFileSystem
.getIRODSAccessObjectFactory().getMountedCollectionAO(
irodsAccount);
String mountedDir = publicDir + "/" + softLinkSubdir;
mountedCollectionAO.unmountACollection(mountedDir,
irodsAccount.getDefaultStorageResource());
// create a soft link between the 'irodsFile' that is the top subdir in
// the user directory to the public directory
mountedCollectionAO.createASoftLink(irodsFile.getAbsolutePath(),
mountedDir);
// now get one of the files
String localCollectionAbsolutePath = scratchFileUtils
.createAndReturnAbsoluteScratchPath(IRODS_TEST_SUBDIR_PATH
+ '/' + localRetrievedDir);
dataTransferOperations.getOperation(mountedDir,
localCollectionAbsolutePath, "", null, null);
File returnDirFile = new File(localCollectionAbsolutePath);
Assert.assertTrue("local dir not created", returnDirFile.exists());
Assert.assertFalse("no files returned",
returnDirFile.listFiles().length == 0);
}
}
Ok, Mike.
Hi John,
I've updated the iRODS issue at the Consortium, it is a server issue, it appears. We probably should start thinking about short term work arouns, such as doing a copy to public?
Unfortunately, we cannot afford the space to have multiple copies. These model runs are on the order of 10-100 TB collections.
Hey John,
One thing that might be too obvious. but do you have permission on the public folder that is 'inherited' and has the anonymous group? Did Wayne talk to you about that fact?
Hi Mike. I'll check on that. I don't remember whether Wayne and I spoke about that. Why would that explain why it works with icommands but not iDrop? J.
On 9/9/14, 1:19 AM, Mike Conway wrote:
Hey John,
One thing that might be too obvious. but do you have permission on the public folder that is 'inherited' and has the anonymous group? Did Wayne talk to you about that fact?
— Reply to this email directly or view it on GitHub https://github.com/DICE-UNC/idrop/issues/54#issuecomment-54955205.
Hi John,
What I found was that it worked in icommands because my own irodsEnv was set to my user name, when I switched the irodsEnv to be the actual anonymous user it failed.
Does that match your experience?
On Tue, Sep 9, 2014 at 1:56 PM, hellyj notifications@github.com wrote:
Hi Mike. I'll check on that. I don't remember whether Wayne and I spoke about that. Why would that explain why it works with icommands but not iDrop? J.
On 9/9/14, 1:19 AM, Mike Conway wrote:
Hey John,
One thing that might be too obvious. but do you have permission on the public folder that is 'inherited' and has the anonymous group? Did Wayne talk to you about that fact?
— Reply to this email directly or view it on GitHub https://github.com/DICE-UNC/idrop/issues/54#issuecomment-54955205.
— Reply to this email directly or view it on GitHub https://github.com/DICE-UNC/idrop/issues/54#issuecomment-55009283.
I'll do that test tonight. Wayne and I used the export command to set the username. I'll try it with the .irods/.irodsEnv file and report back. J.
On 9/9/14, 9:06 AM, Mike Conway wrote:
Hi John,
What I found was that it worked in icommands because my own irodsEnv was set to my user name, when I switched the irodsEnv to be the actual anonymous user it failed.
Does that match your experience?
On Tue, Sep 9, 2014 at 1:56 PM, hellyj notifications@github.com wrote:
Hi Mike. I'll check on that. I don't remember whether Wayne and I spoke about that. Why would that explain why it works with icommands but not iDrop? J.
On 9/9/14, 1:19 AM, Mike Conway wrote:
Hey John,
One thing that might be too obvious. but do you have permission on the public folder that is 'inherited' and has the anonymous group? Did Wayne talk to you about that fact?
— Reply to this email directly or view it on GitHub https://github.com/DICE-UNC/idrop/issues/54#issuecomment-54955205.
— Reply to this email directly or view it on GitHub https://github.com/DICE-UNC/idrop/issues/54#issuecomment-55009283.
— Reply to this email directly or view it on GitHub https://github.com/DICE-UNC/idrop/issues/54#issuecomment-55017707.
that would be great. I can see that same effect when I do that in jargon (using a named user versus public)
On Tue, Sep 9, 2014 at 4:03 PM, hellyj notifications@github.com wrote:
I'll do that test tonight. Wayne and I used the export command to set the username. I'll try it with the .irods/.irodsEnv file and report back. J.
On 9/9/14, 9:06 AM, Mike Conway wrote:
Hi John,
What I found was that it worked in icommands because my own irodsEnv was set to my user name, when I switched the irodsEnv to be the actual anonymous user it failed.
Does that match your experience?
On Tue, Sep 9, 2014 at 1:56 PM, hellyj notifications@github.com wrote:
Hi Mike. I'll check on that. I don't remember whether Wayne and I spoke about that. Why would that explain why it works with icommands but not iDrop? J.
On 9/9/14, 1:19 AM, Mike Conway wrote:
Hey John,
One thing that might be too obvious. but do you have permission on the public folder that is 'inherited' and has the anonymous group? Did Wayne talk to you about that fact?
— Reply to this email directly or view it on GitHub https://github.com/DICE-UNC/idrop/issues/54#issuecomment-54955205.
— Reply to this email directly or view it on GitHub https://github.com/DICE-UNC/idrop/issues/54#issuecomment-55009283.
— Reply to this email directly or view it on GitHub https://github.com/DICE-UNC/idrop/issues/54#issuecomment-55017707.
— Reply to this email directly or view it on GitHub https://github.com/DICE-UNC/idrop/issues/54#issuecomment-55025055.
You mean versus 'anonymous', correct? J.
On 9/9/14, 10:09 AM, Mike Conway wrote:
that would be great. I can see that same effect when I do that in jargon (using a named user versus public)
On Tue, Sep 9, 2014 at 4:03 PM, hellyj notifications@github.com wrote:
I'll do that test tonight. Wayne and I used the export command to set the username. I'll try it with the .irods/.irodsEnv file and report back. J.
On 9/9/14, 9:06 AM, Mike Conway wrote:
Hi John,
What I found was that it worked in icommands because my own irodsEnv was set to my user name, when I switched the irodsEnv to be the actual anonymous user it failed.
Does that match your experience?
On Tue, Sep 9, 2014 at 1:56 PM, hellyj notifications@github.com wrote:
Hi Mike. I'll check on that. I don't remember whether Wayne and I spoke about that. Why would that explain why it works with icommands but not iDrop? J.
On 9/9/14, 1:19 AM, Mike Conway wrote:
Hey John,
One thing that might be too obvious. but do you have permission on the public folder that is 'inherited' and has the anonymous group? Did Wayne talk to you about that fact?
— Reply to this email directly or view it on GitHub
https://github.com/DICE-UNC/idrop/issues/54#issuecomment-54955205.
— Reply to this email directly or view it on GitHub https://github.com/DICE-UNC/idrop/issues/54#issuecomment-55009283.
— Reply to this email directly or view it on GitHub https://github.com/DICE-UNC/idrop/issues/54#issuecomment-55017707.
— Reply to this email directly or view it on GitHub https://github.com/DICE-UNC/idrop/issues/54#issuecomment-55025055.
— Reply to this email directly or view it on GitHub https://github.com/DICE-UNC/idrop/issues/54#issuecomment-55025800.
yes. User anonymous in the group public, with the public dir having inheritance turned on and the group public having rights.
I think an issue is that iRODS, with soft links, might be making the wrong database query, and using the source collection as the source of ACL rights, rather than the soft link.
In that case, we can think about a shim where we set the access rights in the source (original location) to allow public and try that again.
On Tue, Sep 9, 2014 at 4:18 PM, hellyj notifications@github.com wrote:
You mean versus 'anonymous', correct? J.
On 9/9/14, 10:09 AM, Mike Conway wrote:
that would be great. I can see that same effect when I do that in jargon (using a named user versus public)
On Tue, Sep 9, 2014 at 4:03 PM, hellyj notifications@github.com wrote:
I'll do that test tonight. Wayne and I used the export command to set the username. I'll try it with the .irods/.irodsEnv file and report back. J.
On 9/9/14, 9:06 AM, Mike Conway wrote:
Hi John,
What I found was that it worked in icommands because my own irodsEnv was set to my user name, when I switched the irodsEnv to be the actual anonymous user it failed.
Does that match your experience?
On Tue, Sep 9, 2014 at 1:56 PM, hellyj notifications@github.com wrote:
Hi Mike. I'll check on that. I don't remember whether Wayne and I spoke about that. Why would that explain why it works with icommands but not iDrop? J.
On 9/9/14, 1:19 AM, Mike Conway wrote:
Hey John,
One thing that might be too obvious. but do you have permission on the public folder that is 'inherited' and has the anonymous group? Did Wayne talk to you about that fact?
— Reply to this email directly or view it on GitHub
https://github.com/DICE-UNC/idrop/issues/54#issuecomment-54955205.
— Reply to this email directly or view it on GitHub <https://github.com/DICE-UNC/idrop/issues/54#issuecomment-55009283 .
— Reply to this email directly or view it on GitHub https://github.com/DICE-UNC/idrop/issues/54#issuecomment-55017707.
— Reply to this email directly or view it on GitHub https://github.com/DICE-UNC/idrop/issues/54#issuecomment-55025055.
— Reply to this email directly or view it on GitHub https://github.com/DICE-UNC/idrop/issues/54#issuecomment-55025800.
— Reply to this email directly or view it on GitHub https://github.com/DICE-UNC/idrop/issues/54#issuecomment-55027651.
Hi Mike.
The icommand test works with user 'anonymous' and the directory 'public'. I can 'iget' files that are linked to actually copies. Here is a copy of the .irods/.irodEnv that I used. Feel free to try it yourself.
#
#
irodsHost 'cmmap001.sdsc.edu'
irodsPort 1247
irodsDefResource 'cmmap001'
irodsHome '/cmmap001/home/public'
irodsCwd '/cmmap001/home/public'
irodsUserName 'anonymous'
irodsZone 'cmmap001'
On 9/9/14, 10:33 AM, Mike Conway wrote:
yes. User anonymous in the group public, with the public dir having inheritance turned on and the group public having rights.
I think an issue is that iRODS, with soft links, might be making the wrong database query, and using the source collection as the source of ACL rights, rather than the soft link.
In that case, we can think about a shim where we set the access rights in the source (original location) to allow public and try that again.
On Tue, Sep 9, 2014 at 4:18 PM, hellyj notifications@github.com wrote:
You mean versus 'anonymous', correct? J.
On 9/9/14, 10:09 AM, Mike Conway wrote:
that would be great. I can see that same effect when I do that in jargon (using a named user versus public)
On Tue, Sep 9, 2014 at 4:03 PM, hellyj notifications@github.com wrote:
I'll do that test tonight. Wayne and I used the export command to set the username. I'll try it with the .irods/.irodsEnv file and report back. J.
On 9/9/14, 9:06 AM, Mike Conway wrote:
Hi John,
What I found was that it worked in icommands because my own irodsEnv was set to my user name, when I switched the irodsEnv to be the actual anonymous user it failed.
Does that match your experience?
On Tue, Sep 9, 2014 at 1:56 PM, hellyj notifications@github.com wrote:
Hi Mike. I'll check on that. I don't remember whether Wayne and I spoke about that. Why would that explain why it works with icommands but not iDrop? J.
On 9/9/14, 1:19 AM, Mike Conway wrote:
Hey John,
One thing that might be too obvious. but do you have permission on the public folder that is 'inherited' and has the anonymous group? Did Wayne talk to you about that fact?
— Reply to this email directly or view it on GitHub
https://github.com/DICE-UNC/idrop/issues/54#issuecomment-54955205.
— Reply to this email directly or view it on GitHub
<https://github.com/DICE-UNC/idrop/issues/54#issuecomment-55009283 .
— Reply to this email directly or view it on GitHub
https://github.com/DICE-UNC/idrop/issues/54#issuecomment-55017707.
— Reply to this email directly or view it on GitHub https://github.com/DICE-UNC/idrop/issues/54#issuecomment-55025055.
— Reply to this email directly or view it on GitHub https://github.com/DICE-UNC/idrop/issues/54#issuecomment-55025800.
— Reply to this email directly or view it on GitHub https://github.com/DICE-UNC/idrop/issues/54#issuecomment-55027651.
— Reply to this email directly or view it on GitHub https://github.com/DICE-UNC/idrop/issues/54#issuecomment-55029984.
OK thanks John, I’ll take a look this morning MC
On Sep 10, 2014, at 2:56 AM, hellyj notifications@github.com wrote:
Hi Mike.
The icommand test works with user 'anonymous' and the directory 'public'. I can 'iget' files that are linked to actually copies. Here is a copy of the .irods/.irodEnv that I used. Feel free to try it yourself.
iRODS personal configuration file.
#
This file was automatically created during iRODS installation.
Created Sun Jul 18 13:06:23 2010
#
iRODS server host name:
irodsHost 'cmmap001.sdsc.edu'
iRODS server port number:
irodsPort 1247
Default storage resource name:
irodsDefResource 'cmmap001'
Home directory in iRODS:
irodsHome '/cmmap001/home/hellyj'
irodsHome '/cmmap001/home/public'
Current directory in iRODS:
irodsCwd '/cmmap001/home/hellyj'
irodsCwd '/cmmap001/home/public'
Account name:
irodsUserName 'hellyj'
irodsUserName 'anonymous'
Zone:
irodsZone 'cmmap001'
On 9/9/14, 10:33 AM, Mike Conway wrote:
yes. User anonymous in the group public, with the public dir having inheritance turned on and the group public having rights.
I think an issue is that iRODS, with soft links, might be making the wrong database query, and using the source collection as the source of ACL rights, rather than the soft link.
In that case, we can think about a shim where we set the access rights in the source (original location) to allow public and try that again.
On Tue, Sep 9, 2014 at 4:18 PM, hellyj notifications@github.com wrote:
You mean versus 'anonymous', correct? J.
On 9/9/14, 10:09 AM, Mike Conway wrote:
that would be great. I can see that same effect when I do that in jargon (using a named user versus public)
On Tue, Sep 9, 2014 at 4:03 PM, hellyj notifications@github.com wrote:
I'll do that test tonight. Wayne and I used the export command to set the username. I'll try it with the .irods/.irodsEnv file and report back. J.
On 9/9/14, 9:06 AM, Mike Conway wrote:
Hi John,
What I found was that it worked in icommands because my own irodsEnv was set to my user name, when I switched the irodsEnv to be the actual anonymous user it failed.
Does that match your experience?
On Tue, Sep 9, 2014 at 1:56 PM, hellyj notifications@github.com wrote:
Hi Mike. I'll check on that. I don't remember whether Wayne and I spoke about that. Why would that explain why it works with icommands but not iDrop? J.
On 9/9/14, 1:19 AM, Mike Conway wrote:
Hey John,
One thing that might be too obvious. but do you have permission on the public folder that is 'inherited' and has the anonymous group? Did Wayne talk to you about that fact?
— Reply to this email directly or view it on GitHub
https://github.com/DICE-UNC/idrop/issues/54#issuecomment-54955205.
— Reply to this email directly or view it on GitHub
<https://github.com/DICE-UNC/idrop/issues/54#issuecomment-55009283 .
— Reply to this email directly or view it on GitHub
https://github.com/DICE-UNC/idrop/issues/54#issuecomment-55017707.
— Reply to this email directly or view it on GitHub https://github.com/DICE-UNC/idrop/issues/54#issuecomment-55025055.
— Reply to this email directly or view it on GitHub https://github.com/DICE-UNC/idrop/issues/54#issuecomment-55025800.
— Reply to this email directly or view it on GitHub https://github.com/DICE-UNC/idrop/issues/54#issuecomment-55027651.
— Reply to this email directly or view it on GitHub https://github.com/DICE-UNC/idrop/issues/54#issuecomment-55029984.
— Reply to this email directly or view it on GitHub.
Hi John,
I've got iDrop web running locally and they are currently downloading using the guest account here, I'll update you when they complete...they are rather large.
I'm currently downloading GATE_IDEAL_S_00450_127_to_140.nc
If this works here, I'll deploy this to another server instance and have you try it
iDrop desktop is also working. DId someone update the ACLs on the public directory or similar? I have successfully downloaded from /home/public/GigaLES_010/CMMAP_SAM6.7SR_OUT3D_netCDF using iDrop desktop and iDrop web.
Log from a successful iDrop web transfer running on my desktop
2014-09-12 09:46:29,735 [http-bio-8080-exec-4] INFO io.IRODSFileImpl - length() for path:/cmmap001/home/public/GigaLES_010/CMMAP_SAM6.7SR_OUT3D_netCDF/GATE_IDEAL_S_00450_001_to_014.nc
2014-09-12 09:46:29,736 [http-bio-8080-exec-4] INFO pub.IRODSFileSystemAOImpl - getObjStat(final String irodsAbsolutePath)
2014-09-12 09:46:29,816 [http-bio-8080-exec-4] INFO pub.CollectionAndDataObjectListAndSearchAOImpl - objStat:
absolutePath:/cmmap001/home/public/GigaLES_010/CMMAP_SAM6.7SR_OUT3D_netCDF/GATE_IDEAL_S_00450_001_to_014.nc
dataId:30546
specColType:LINKED_COLL
objectType:DATA_OBJECT
collectionPath:/cmmap001/home/public/GigaLES_010
objectPath:/cmmap001/home/GigaLES_010/CMMAP_SAM6.7SR_OUT3D_netCDF/GATE_IDEAL_S_00450_001_to_014.nc
checksum:6a1764e035513da94a1bfa228b804589
ownerName:hellyj
ownerZone:cmmap001
objSize:1879066636
cacheDir:
cacheDirty:false
createdAt:replNumber:0Mon Jun 16 19:34:54 EDT 2014
modifiedAt:Mon Jun 16 19:34:54 EDT 2014
2014-09-12 09:46:29,958 [http-bio-8080-exec-4] INFO io.IRODSFileInputStream - closing file stream and file
2014-09-12 09:46:29,958 [http-bio-8080-exec-4] INFO io.IRODSFileImpl - closing irodsFile:/cmmap001/home/public/GigaLES_010/CMMAP_SAM6.7SR_OUT3D_netCDF/GATE_IDEAL_S_00450_001_to_014.nc
2014-09-12 09:46:29,959 [http-bio-8080-exec-4] INFO pub.IRODSFileSystemAOImpl - ileClose(final int fileDescriptor) :3
2014-09-12 09:46:30,030 [http-bio-8080-exec-4] INFO pub.Stream2StreamAOImpl - transfer stats:TransferStatistics
totalByte:1879066636
seconds:655
kbPerSecond:2868804
2014-09-12 09:46:30,031 [http-bio-8080-exec-4] INFO controller.FileController - transferStats:TransferStatistics
totalByte:1879066636
seconds:655
kbPerSecond:2868804
2014-09-12 09:46:30,032 [http-bio-8080-exec-4] DEBUG controller.FileController - closing the session
2014-09-12 09:49:30,854 [http-bio-8080-exec-9] INFO io.IRODSFileImpl - length() for path:/cmmap001/home/public/GigaLES_010/CMMAP_SAM6.7SR_OUT3D_netCDF/GATE_IDEAL_S_00450_127_to_140.nc
2014-09-12 09:49:30,855 [http-bio-8080-exec-9] INFO pub.IRODSFileSystemAOImpl - getObjStat(final String irodsAbsolutePath)
2014-09-12 09:49:30,934 [http-bio-8080-exec-9] INFO pub.CollectionAndDataObjectListAndSearchAOImpl - objStat:
absolutePath:/cmmap001/home/public/GigaLES_010/CMMAP_SAM6.7SR_OUT3D_netCDF/GATE_IDEAL_S_00450_127_to_140.nc
dataId:30625
specColType:LINKED_COLL
objectType:DATA_OBJECT
collectionPath:/cmmap001/home/public/GigaLES_010
objectPath:/cmmap001/home/GigaLES_010/CMMAP_SAM6.7SR_OUT3D_netCDF/GATE_IDEAL_S_00450_127_to_140.nc
checksum:68d4604756f76ab958be1540a5428fb6
ownerName:hellyj
ownerZone:cmmap001
objSize:1879066636
cacheDir:
cacheDirty:false
createdAt:replNumber:0Mon Jun 16 19:56:25 EDT 2014
modifiedAt:Mon Jun 16 19:56:25 EDT 2014
2014-09-12 09:49:31,076 [http-bio-8080-exec-9] INFO io.IRODSFileInputStream - closing file stream and file
2014-09-12 09:49:31,077 [http-bio-8080-exec-9] INFO io.IRODSFileImpl - closing irodsFile:/cmmap001/home/public/GigaLES_010/CMMAP_SAM6.7SR_OUT3D_netCDF/GATE_IDEAL_S_00450_127_to_140.nc
2014-09-12 09:49:31,077 [http-bio-8080-exec-9] INFO pub.IRODSFileSystemAOImpl - ileClose(final int fileDescriptor) :3
2014-09-12 09:49:31,148 [http-bio-8080-exec-9] INFO pub.Stream2StreamAOImpl - transfer stats:TransferStatistics
totalByte:1879066636
seconds:644
kbPerSecond:2917805
2014-09-12 09:49:31,148 [http-bio-8080-exec-9] INFO controller.FileController - transferStats:TransferStatistics
totalByte:1879066636
seconds:644
kbPerSecond:2917805
2014-09-12 09:49:31,149 [http-bio-8080-exec-9] DEBUG controller.FileController - closing the session
Great. Thanks. J.
On 9/12/14, 3:42 AM, Mike Conway wrote:
Hi John,
I've got iDrop web running locally and they are currently downloading using the guest account here, I'll update you when they complete...they are rather large.
I'm currently downloading GATE_IDEAL_S_00450_127_to_140.nc
If this works here, I'll deploy this to another server instance and have you try it
— Reply to this email directly or view it on GitHub https://github.com/DICE-UNC/idrop/issues/54#issuecomment-55404854.
No, nothing has changed. J.
On 9/12/14, 3:59 AM, Mike Conway wrote:
iDrop desktop is also working. DId someone update the ACLs on the public directory or similar? I have successfully downloaded from /home/public/GigaLES_010/CMMAP_SAM6.7SR_OUT3D_netCDF using iDrop desktop and iDrop web.
— Reply to this email directly or view it on GitHub https://github.com/DICE-UNC/idrop/issues/54#issuecomment-55406907.
Hi John,
I was able to complete downloads in idrop web and idrop desktop to that /home/public dir, so that is somewhat confusing! I'm trying to set up an alternate server for you to log into to sign into idrop web.
MC
On Fri, Sep 12, 2014 at 2:00 PM, hellyj notifications@github.com wrote:
No, nothing has changed. J.
On 9/12/14, 3:59 AM, Mike Conway wrote:
iDrop desktop is also working. DId someone update the ACLs on the public directory or similar? I have successfully downloaded from /home/public/GigaLES_010/CMMAP_SAM6.7SR_OUT3D_netCDF using iDrop desktop and iDrop web.
— Reply to this email directly or view it on GitHub https://github.com/DICE-UNC/idrop/issues/54#issuecomment-55406907.
— Reply to this email directly or view it on GitHub https://github.com/DICE-UNC/idrop/issues/54#issuecomment-55439042.
Most of the data are on a resource server that is federated with the primary. Sometimes that server hangs due to a firmware problem. Is it possible for iRODS to 'think' it is downloading something and then produce a zero-length file on the target if a resource server is down without throwing an error?
This could explain the inconsistent results.
J.
On 9/12/14, 8:39 AM, Mike Conway wrote:
Hi John,
I was able to complete downloads in idrop web and idrop desktop to that /home/public dir, so that is somewhat confusing! I'm trying to set up an alternate server for you to log into to sign into idrop web.
MC
On Fri, Sep 12, 2014 at 2:00 PM, hellyj notifications@github.com wrote:
No, nothing has changed. J.
On 9/12/14, 3:59 AM, Mike Conway wrote:
iDrop desktop is also working. DId someone update the ACLs on the public directory or similar? I have successfully downloaded from /home/public/GigaLES_010/CMMAP_SAM6.7SR_OUT3D_netCDF using iDrop desktop and iDrop web.
— Reply to this email directly or view it on GitHub https://github.com/DICE-UNC/idrop/issues/54#issuecomment-55406907.
— Reply to this email directly or view it on GitHub https://github.com/DICE-UNC/idrop/issues/54#issuecomment-55439042.
— Reply to this email directly or view it on GitHub https://github.com/DICE-UNC/idrop/issues/54#issuecomment-55443640.
Hi John,
I was getting, in my testing, an error making a particular request to irods (getting an ObjStat, which is a summary set of data about a file).
I would get a DataNotFound exception, which can happen when there is an access problem due to security. I WAS getting that! You can page up in that log and see where it was occurring. In my tests today it DID NOT OCCUR. That is very odd. I'm sorry, this has been such a confusing issue. I'm working on getting a server up and running to have you test it out.
On Fri, Sep 12, 2014 at 2:48 PM, hellyj notifications@github.com wrote:
Most of the data are on a resource server that is federated with the primary. Sometimes that server hangs due to a firmware problem. Is it possible for iRODS to 'think' it is downloading something and then produce a zero-length file on the target if a resource server is down without throwing an error?
This could explain the inconsistent results.
J.
On 9/12/14, 8:39 AM, Mike Conway wrote:
Hi John,
I was able to complete downloads in idrop web and idrop desktop to that /home/public dir, so that is somewhat confusing! I'm trying to set up an alternate server for you to log into to sign into idrop web.
MC
On Fri, Sep 12, 2014 at 2:00 PM, hellyj notifications@github.com wrote:
No, nothing has changed. J.
On 9/12/14, 3:59 AM, Mike Conway wrote:
iDrop desktop is also working. DId someone update the ACLs on the public directory or similar? I have successfully downloaded from /home/public/GigaLES_010/CMMAP_SAM6.7SR_OUT3D_netCDF using iDrop desktop and iDrop web.
— Reply to this email directly or view it on GitHub https://github.com/DICE-UNC/idrop/issues/54#issuecomment-55406907.
— Reply to this email directly or view it on GitHub https://github.com/DICE-UNC/idrop/issues/54#issuecomment-55439042.
— Reply to this email directly or view it on GitHub https://github.com/DICE-UNC/idrop/issues/54#issuecomment-55443640.
— Reply to this email directly or view it on GitHub https://github.com/DICE-UNC/idrop/issues/54#issuecomment-55444698.
Hi Mike.
I just re-tested and get the same results: iDrop produces only zero-length files while iget produces a proper copy.
Maybe we should schedule a shared desktop session for next week?
J.
On 9/12/14, 9:05 AM, Mike Conway wrote:
Hi John,
I was getting, in my testing, an error making a particular request to irods (getting an ObjStat, which is a summary set of data about a file).
I would get a DataNotFound exception, which can happen when there is an access problem due to security. I WAS getting that! You can page up in that log and see where it was occurring. In my tests today it DID NOT OCCUR. That is very odd. I'm sorry, this has been such a confusing issue. I'm working on getting a server up and running to have you test it out.
On Fri, Sep 12, 2014 at 2:48 PM, hellyj notifications@github.com wrote:
Most of the data are on a resource server that is federated with the primary. Sometimes that server hangs due to a firmware problem. Is it possible for iRODS to 'think' it is downloading something and then produce a zero-length file on the target if a resource server is down without throwing an error?
This could explain the inconsistent results.
J.
On 9/12/14, 8:39 AM, Mike Conway wrote:
Hi John,
I was able to complete downloads in idrop web and idrop desktop to that /home/public dir, so that is somewhat confusing! I'm trying to set up an alternate server for you to log into to sign into idrop web.
MC
On Fri, Sep 12, 2014 at 2:00 PM, hellyj notifications@github.com wrote:
No, nothing has changed. J.
On 9/12/14, 3:59 AM, Mike Conway wrote:
iDrop desktop is also working. DId someone update the ACLs on the public directory or similar? I have successfully downloaded from /home/public/GigaLES_010/CMMAP_SAM6.7SR_OUT3D_netCDF using iDrop desktop and iDrop web.
— Reply to this email directly or view it on GitHub
https://github.com/DICE-UNC/idrop/issues/54#issuecomment-55406907.
— Reply to this email directly or view it on GitHub https://github.com/DICE-UNC/idrop/issues/54#issuecomment-55439042.
— Reply to this email directly or view it on GitHub https://github.com/DICE-UNC/idrop/issues/54#issuecomment-55443640.
— Reply to this email directly or view it on GitHub https://github.com/DICE-UNC/idrop/issues/54#issuecomment-55444698.
— Reply to this email directly or view it on GitHub https://github.com/DICE-UNC/idrop/issues/54#issuecomment-55446908.
yes, it makes no sense…
I can do Monday all day or Tuesday morning?
MC
On Sep 13, 2014, at 7:33 PM, hellyj notifications@github.com wrote:
Hi Mike.
I just re-tested and get the same results: iDrop produces only zero-length files while iget produces a proper copy.
Maybe we should schedule a shared desktop session for next week?
J.
On 9/12/14, 9:05 AM, Mike Conway wrote:
Hi John,
I was getting, in my testing, an error making a particular request to irods (getting an ObjStat, which is a summary set of data about a file).
I would get a DataNotFound exception, which can happen when there is an access problem due to security. I WAS getting that! You can page up in that log and see where it was occurring. In my tests today it DID NOT OCCUR. That is very odd. I'm sorry, this has been such a confusing issue. I'm working on getting a server up and running to have you test it out.
On Fri, Sep 12, 2014 at 2:48 PM, hellyj notifications@github.com wrote:
Most of the data are on a resource server that is federated with the primary. Sometimes that server hangs due to a firmware problem. Is it possible for iRODS to 'think' it is downloading something and then produce a zero-length file on the target if a resource server is down without throwing an error?
This could explain the inconsistent results.
J.
On 9/12/14, 8:39 AM, Mike Conway wrote:
Hi John,
I was able to complete downloads in idrop web and idrop desktop to that /home/public dir, so that is somewhat confusing! I'm trying to set up an alternate server for you to log into to sign into idrop web.
MC
On Fri, Sep 12, 2014 at 2:00 PM, hellyj notifications@github.com wrote:
No, nothing has changed. J.
On 9/12/14, 3:59 AM, Mike Conway wrote:
iDrop desktop is also working. DId someone update the ACLs on the public directory or similar? I have successfully downloaded from /home/public/GigaLES_010/CMMAP_SAM6.7SR_OUT3D_netCDF using iDrop desktop and iDrop web.
— Reply to this email directly or view it on GitHub
https://github.com/DICE-UNC/idrop/issues/54#issuecomment-55406907.
— Reply to this email directly or view it on GitHub https://github.com/DICE-UNC/idrop/issues/54#issuecomment-55439042.
— Reply to this email directly or view it on GitHub https://github.com/DICE-UNC/idrop/issues/54#issuecomment-55443640.
— Reply to this email directly or view it on GitHub https://github.com/DICE-UNC/idrop/issues/54#issuecomment-55444698.
— Reply to this email directly or view it on GitHub https://github.com/DICE-UNC/idrop/issues/54#issuecomment-55446908.
— Reply to this email directly or view it on GitHub.
issue was default storage resource...resolved.
I'm GET'ing from a mounted collection in public. When I do an iget from the command-line tools it works fine but iDrop produces zero-length files.
log info