Closed anderbubble closed 4 years ago
Here's the traceback from the nfsrods process. (It's the same whether we specify -f
or not.)
2020-06-22 07:21:33.728 ERROR Thread-64 [IRODSVirtualFileSystem] - Attempt to overwrite file without force flag
2020-06-22 07:21:33.728 ERROR Thread-64 [NFSServerV41] - Unhandled exception:
java.io.IOException: org.irods.jargon.core.exception.JargonFileOrCollAlreadyExistsException: Attempt to overwrite file without force flag
at org.irods.nfsrods.vfs.IRODSVirtualFileSystem.move(IRODSVirtualFileSystem.java:1061) ~[nfsrods-0.9.3-jar-with-dependencies.jar:?]
at org.dcache.nfs.vfs.PseudoFs.move(PseudoFs.java:233) ~[nfsrods-0.9.3-jar-with-dependencies.jar:?]
at org.dcache.nfs.v4.OperationRENAME.process(OperationRENAME.java:83) ~[nfsrods-0.9.3-jar-with-dependencies.jar:?]
at org.dcache.nfs.v4.NFSServerV41.NFSPROC4_COMPOUND_4(NFSServerV41.java:204) ~[nfsrods-0.9.3-jar-with-dependencies.jar:?]
at org.dcache.nfs.v4.xdr.nfs4_prot_NFS4_PROGRAM_ServerStub.dispatchOncRpcCall(nfs4_prot_NFS4_PROGRAM_ServerStub.java:48) ~[nfsrods-0.9.3-jar-with-dependencies.jar:?]
at org.dcache.oncrpc4j.rpc.RpcDispatcher$1.lambda$run$0(RpcDispatcher.java:100) ~[nfsrods-0.9.3-jar-with-dependencies.jar:?]
at java.security.AccessController.doPrivileged(Native Method) ~[?:1.8.0_222]
at javax.security.auth.Subject.doAs(Subject.java:422) ~[?:1.8.0_222]
at org.dcache.oncrpc4j.rpc.RpcDispatcher$1.run(RpcDispatcher.java:99) ~[nfsrods-0.9.3-jar-with-dependencies.jar:?]
at org.glassfish.grizzly.threadpool.AbstractThreadPool$Worker.doWork(AbstractThreadPool.java:593) ~[nfsrods-0.9.3-jar-with-dependencies.jar:?]
at org.glassfish.grizzly.threadpool.AbstractThreadPool$Worker.run(AbstractThreadPool.java:573) ~[nfsrods-0.9.3-jar-with-dependencies.jar:?]
at java.lang.Thread.run(Thread.java:748) [?:1.8.0_222]
Caused by: org.irods.jargon.core.exception.JargonFileOrCollAlreadyExistsException: Attempt to overwrite file without force flag
at org.irods.jargon.core.connection.IRODSErrorScanner.checkSpecificCodesAndThrowIfExceptionLocated(IRODSErrorScanner.java:142) ~[nfsrods-0.9.3-jar-with-dependencies.jar:?]
at org.irods.jargon.core.connection.IRODSErrorScanner.inspectAndThrowIfNeeded(IRODSErrorScanner.java:115) ~[nfsrods-0.9.3-jar-with-dependencies.jar:?]
at org.irods.jargon.core.connection.IRODSMidLevelProtocol.processMessageInfoLessThanZero(IRODSMidLevelProtocol.java:1399) ~[nfsrods-0.9.3-jar-with-dependencies.jar:?]
at org.irods.jargon.core.connection.IRODSMidLevelProtocol.readMessage(IRODSMidLevelProtocol.java:903) ~[nfsrods-0.9.3-jar-with-dependencies.jar:?]
at org.irods.jargon.core.connection.IRODSMidLevelProtocol.readMessage(IRODSMidLevelProtocol.java:871) ~[nfsrods-0.9.3-jar-with-dependencies.jar:?]
at org.irods.jargon.core.connection.IRODSMidLevelProtocol.irodsFunction(IRODSMidLevelProtocol.java:284) ~[nfsrods-0.9.3-jar-with-dependencies.jar:?]
at org.irods.jargon.core.connection.IRODSMidLevelProtocol.irodsFunction(IRODSMidLevelProtocol.java:410) ~[nfsrods-0.9.3-jar-with-dependencies.jar:?]
at org.irods.jargon.core.pub.IRODSFileSystemAOImpl.renameFile(IRODSFileSystemAOImpl.java:1176) ~[nfsrods-0.9.3-jar-with-dependencies.jar:?]
at org.irods.nfsrods.vfs.IRODSVirtualFileSystem.move(IRODSVirtualFileSystem.java:1043) ~[nfsrods-0.9.3-jar-with-dependencies.jar:?]
... 11 more
Okay, so definitely a bug when the -f
is present.
However, since there's no way to inform the user about their lack of -f
... we need to decide whether to:
1) leave as-is when no -f
present - user sees an I/O Error. A bit messy and unhelpful, but no surprises on the server side ("oops, data is overwritten")
or
2) always behave as if -f
is present - always overwrite on the server side. Clean, but could result in surprising loss of existing data.
I don't like either 1 or 2 at this time - but we'd have to lean towards 1 (no data loss).
Is there a third way?
I'd think the overwrite 'gesture' in a file system is a pretty clear user intent, so I'd suggest we add a flag and by default allow overwrite. It should be relatively straightforward. Not so much a bug as a 'what's the least surprising default question. I can help with any code ?s.
To be clear... in the face of a request without a -f
flag... @michael-conway, you are advocating for option 2, always behave as if -f
is present, always force overwrite? Seems... more dangerous than option 1.
there's no way to inform the user about their lack of -f
Overwrite is the default, expected behavior, and should be allowed in all cases with NFSRODS. The -f
flag in mv
is an interface issue, not an fs issue, as it simply overrides a previous -n
or -i
.
[joan5896@admin2 joan5896]$ touch newfile
[joan5896@admin2 joan5896]$ touch newfile2
[joan5896@admin2 joan5896]$ mv newfile2 newfile
[joan5896@admin2 joan5896]$ ls newfile newfile2
ls: cannot access newfile2: No such file or directory
newfile
To be clear, NFSRODS doesn't know whether mv
was run with -f
or not, so you can't differentiate. If you ever want to allow overwrite with NFSRODS, you must always allow overwrite. And since that's what a posix fs is supposed to do, that's what NFSRODS should do.
Ah, very good - didn't realize it doesn't get conveyed to the filesystem.
Okay, so option 2 it is. Thanks.
I'm talking about a property in the configs where the default would be to allow overwrite, since it seems a user interacting with a file explorer who drops a file wants that to be the new bits, etc.
So default=overwrite is implied but as a user you have the option at deploy time to change it.
Even better. So... we get to name a new configuration option...
{
"nfs_server": {
"allow_overwrites_of_existing_files": "true"
}
}
This... slightly more general wording suggests that it would affect mv
as well as cp
and open/write/close
. Any others? Is this what we want?
This looks good to me; but when this is false please ensure that nfsrods returns a proper error code; not just a generic i/o error due to an unhandled traceback.
I hear you - not sure that's possible with the NFS protocol... will investigate of course.
Jargon interprets the iRODS server response as JargonFileOrCollAlreadyExistsException
... and... as I understand it... doesn't have a mechanism to signal as an NFS server a message to the client for 'why', outside of the existing NFS error codes.
Do you have a particular error code in mind? Perhaps a perfectly singular link to light the way?
Alternately, NFSRODS just goes with option 2 (always uses -f
, behaves like POSIX) and offers no configurability on this point.
https://pubs.opengroup.org/onlinepubs/9699919799/functions/V2_chap02.html
I suggest any of EACCES, EEXIST, EPERM, EROFS, or ENOTSUP as viable, depending on what you most want to signal about the behavior.
In looking for NFS4 errors specifically (listed at https://tools.ietf.org/html/rfc7530#section-13.1)...
@korydraughn can we send NFS4ERR_EXIST
if allow_overwrites_of_existing_files
is set to false
and someone tries to overwrite?
I'll investigate. I know nfs4j has a list of exceptions matching all of the possible errors, I just haven't been successful at getting them to show up on the client.
What's the state of this? Any chance of seeing a fix in an upcoming release?
This should be resolved in the next release. I've just wrapped up development on parallel transfer support in the iRODS server, so I should be able to focus on this very soon.
@michael-conway Are there examples of force overwriting a replica via a move/rename operation? I haven't spotted any test that demonstrates this in the Jargon test suite.
I think we need to add that flag, it appears to not be there in the sig. Not difficult to do, e.g. in DataTransferOperationsImpl..
private void moveOperation(final IRODSFile irodsSourceFile, final IRODSFile
irodsTargetFile)
throws JargonFileOrCollAlreadyExistsException, JargonException {
log.info("moveOperation()");
log.info("target file:{}", irodsTargetFile.getAbsolutePath());
log.info("target file isDir? {}", irodsTargetFile.isDirectory());
IRODSFile actualTargetFile = irodsTargetFile;
if (irodsSourceFile.isFile() && irodsTargetFile.isDirectory()) {
log.info("target file is a directory, automatically propogate the source
file name to the target");
actualTargetFile = getIRODSFileFactory().instanceIRODSFile(irodsTargetFile.
getAbsolutePath(),
irodsSourceFile.getName());
}
if (irodsSourceFile.getAbsolutePath().equals(actualTargetFile.
getAbsolutePath())) {
log.warn("attempt to move a file: {} to the same file name, logged and
ignored");
return;
}
// build correct packing instruction for move. The packing instructions
// are different for files and collections.
DataObjCopyInp dataObjCopyInp = null;
if (irodsSourceFile.isFile()) {
log.info("move is for a file");
dataObjCopyInp = DataObjCopyInp.instanceForRenameFile(irodsSourceFile.
getAbsolutePath(),
actualTargetFile.getAbsolutePath());
} else {
log.info("move is for a collection");
dataObjCopyInp = DataObjCopyInp.instanceForRenameCollection(irodsSourceFile.
getAbsolutePath(),
actualTargetFile.getAbsolutePath());
}
try {
getIRODSProtocol().irodsFunction(dataObjCopyInp);
} catch (JargonException je) {
log.error("jargon exception in move operation", je);
throw je;
}
}
It's supported inside DataObjCopyInp as a flag in the packing instruction, we'll need to add an additional signature and pass it down to the packing instruction. This looks fairly straighforward. Would this address your need?
On Tue, Aug 18, 2020 at 9:21 AM Kory Draughn notifications@github.com wrote:
@michael-conway https://github.com/michael-conway Are there examples of force overwriting a replica via a move/rename operation? I haven't spotted any test that demonstrates this in the Jargon test suite.
— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/irods/irods_client_nfsrods/issues/92#issuecomment-675475259, or unsubscribe https://github.com/notifications/unsubscribe-auth/AAIL4LJO77J4S4WCZ2JTBZTSBJ57FANCNFSM4OEJQDLA .
possibly. i'll try it out and see what happens.
I can jump in and help? The instance() signature for the packing instruction needs to add the parameter, and then a new signature for the move operation with a 'force' flag can be added, the present signature can just wrap a call with force defaulting to false.
On Tue, Aug 18, 2020 at 9:41 AM Kory Draughn notifications@github.com wrote:
possibly. i'll try it out and see what happens.
— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/irods/irods_client_nfsrods/issues/92#issuecomment-675485519, or unsubscribe https://github.com/notifications/unsubscribe-auth/AAIL4LLHBLXZMTBN5IP7IKDSBKAIRANCNFSM4OEJQDLA .
That would certainly speed things up. Maybe we can handle this issue after the working group meeting. I imagine it shouldn't take long.
sounds like a plan
On Tue, Aug 18, 2020 at 9:50 AM Kory Draughn notifications@github.com wrote:
That would certainly speed things up. Maybe we can handle this issue after the working group meeting. I imagine it shouldn't take long.
— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/irods/irods_client_nfsrods/issues/92#issuecomment-675490217, or unsubscribe https://github.com/notifications/unsubscribe-auth/AAIL4LNXZENI4UWFV5ZWMUTSBKBI3ANCNFSM4OEJQDLA .
pushed 4.3.2.0-SNAPSHOT and it's in master. All the present unit tests pass, still work to do to confirm force flag makes it to the packing instruction but at least we can work on adding the NFS calls to the signature with the force method. This is jargon issue https://github.com/DICE-UNC/jargon/issues/363
On Tue, Aug 18, 2020 at 9:50 AM Mike Conway michael.c.conway@gmail.com wrote:
sounds like a plan
On Tue, Aug 18, 2020 at 9:50 AM Kory Draughn notifications@github.com wrote:
That would certainly speed things up. Maybe we can handle this issue after the working group meeting. I imagine it shouldn't take long.
— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/irods/irods_client_nfsrods/issues/92#issuecomment-675490217, or unsubscribe https://github.com/notifications/unsubscribe-auth/AAIL4LNXZENI4UWFV5ZWMUTSBKBI3ANCNFSM4OEJQDLA .
Excellent!
I tried setting the force flag to true on renameFile
and mv
still failed. I also tried using mv -f
, but the result was the same.
I can see that the boolean value is correct deep in Jargon, but I'm not sure if it is making it to the iRODS server. The iRODS server log does not contain any messages (success or failure) following the operation either.
2020-08-18 16:45:19.545 DEBUG Thread-74 [IRODSVirtualFileSystem] - move - Renaming data object from [/tempZone/home/kory/foo] to [/tempZone/home/kory/bar] ...
2020-08-18 16:45:19.545 INFO Thread-74 [IRODSFileSystemAOImpl] - renaming file:/tempZone/home/kory/foo
2020-08-18 16:45:19.545 INFO Thread-74 [IRODSFileSystemAOImpl] - to:/tempZone/home/kory/bar
2020-08-18 16:45:19.545 INFO Thread-74 [IRODSFileSystemAOImpl] - force:true
2020-08-18 16:45:19.545 INFO Thread-74 [IRODSFileImpl] - isFile() for path:/tempZone/home/kory/foo
2020-08-18 16:45:19.545 INFO Thread-74 [IRODSFileSystemAOImpl] - getObjStat(final String irodsAbsolutePath)
2020-08-18 16:45:19.545 INFO Thread-74 [CollectionAndDataObjectListAndSearchAOImpl] - retrieveObjectStatForPathWithHeuristicPathGuessing()
2020-08-18 16:45:19.548 INFO Thread-74 [CollectionListingUtils] - ObjStat [absolutePath=/tempZone/home/kory/foo, objectPath=, objectType=DATA_OBJECT, dataId=10019, checksum=, ownerName=kory, ownerZone=tempZone, objSize=13, createdAt=Tue Aug 18 16:38:07 EDT 2020, modifiedAt=Tue Aug 18 16:38:08 EDT 2020, specColType=NORMAL, collectionPath=, cacheDir=, cacheDirty=false, replNumber
=0, standInGeneratedObjStat=false]
2020-08-18 16:45:19.563 INFO Thread-74 [IRODSFileImpl] - closing irodsFile:/tempZone/home/kory/bar
2020-08-18 16:45:19.563 INFO Thread-74 [IRODSFileImpl] - file is not open, silently ignore
2020-08-18 16:45:19.563 INFO Thread-74 [IRODSFileImpl] - closing irodsFile:/tempZone/home/kory/foo
2020-08-18 16:45:19.563 INFO Thread-74 [IRODSFileImpl] - file is not open, silently ignore
2020-08-18 16:45:19.563 ERROR Thread-74 [IRODSVirtualFileSystem] - Attempt to overwrite file without force flag
2020-08-18 16:45:19.563 ERROR Thread-74 [NFSServerV41] - Unhandled exception:
java.io.IOException: org.irods.jargon.core.exception.JargonFileOrCollAlreadyExistsException: Attempt to overwrite file without force flag
at org.irods.nfsrods.vfs.IRODSVirtualFileSystem.move(IRODSVirtualFileSystem.java:1069) ~[nfsrods-1.0.0-jar-with-dependencies.jar:?]
at org.dcache.nfs.vfs.PseudoFs.move(PseudoFs.java:233) ~[nfsrods-1.0.0-jar-with-dependencies.jar:?]
at org.dcache.nfs.v4.OperationRENAME.process(OperationRENAME.java:83) ~[nfsrods-1.0.0-jar-with-dependencies.jar:?]
at org.dcache.nfs.v4.NFSServerV41.NFSPROC4_COMPOUND_4(NFSServerV41.java:204) ~[nfsrods-1.0.0-jar-with-dependencies.jar:?]
at org.dcache.nfs.v4.xdr.nfs4_prot_NFS4_PROGRAM_ServerStub.dispatchOncRpcCall(nfs4_prot_NFS4_PROGRAM_ServerStub.java:48) ~[nfsrods-1.0.0-jar-with-dependencies.jar:?]
at org.dcache.oncrpc4j.rpc.RpcDispatcher$1.lambda$run$0(RpcDispatcher.java:100) ~[nfsrods-1.0.0-jar-with-dependencies.jar:?]
at java.security.AccessController.doPrivileged(Native Method) ~[?:1.8.0_265]
at javax.security.auth.Subject.doAs(Subject.java:422) ~[?:1.8.0_265]
at org.dcache.oncrpc4j.rpc.RpcDispatcher$1.run(RpcDispatcher.java:99) ~[nfsrods-1.0.0-jar-with-dependencies.jar:?]
at org.glassfish.grizzly.threadpool.AbstractThreadPool$Worker.doWork(AbstractThreadPool.java:593) ~[nfsrods-1.0.0-jar-with-dependencies.jar:?]
at org.glassfish.grizzly.threadpool.AbstractThreadPool$Worker.run(AbstractThreadPool.java:573) ~[nfsrods-1.0.0-jar-with-dependencies.jar:?]
at java.lang.Thread.run(Thread.java:748) [?:1.8.0_265]
Caused by: org.irods.jargon.core.exception.JargonFileOrCollAlreadyExistsException: Attempt to overwrite file without force flag
at org.irods.jargon.core.connection.IRODSErrorScanner.checkSpecificCodesAndThrowIfExceptionLocated(IRODSErrorScanner.java:142) ~[nfsrods-1.0.0-jar-with-dependencies.jar:?]
at org.irods.jargon.core.connection.IRODSErrorScanner.inspectAndThrowIfNeeded(IRODSErrorScanner.java:115) ~[nfsrods-1.0.0-jar-with-dependencies.jar:?]
at org.irods.jargon.core.connection.IRODSMidLevelProtocol.processMessageInfoLessThanZero(IRODSMidLevelProtocol.java:1399) ~[nfsrods-1.0.0-jar-with-dependencies.jar:?]
at org.irods.jargon.core.connection.IRODSMidLevelProtocol.readMessage(IRODSMidLevelProtocol.java:903) ~[nfsrods-1.0.0-jar-with-dependencies.jar:?]
at org.irods.jargon.core.connection.IRODSMidLevelProtocol.readMessage(IRODSMidLevelProtocol.java:871) ~[nfsrods-1.0.0-jar-with-dependencies.jar:?]
at org.irods.jargon.core.connection.IRODSMidLevelProtocol.irodsFunction(IRODSMidLevelProtocol.java:284) ~[nfsrods-1.0.0-jar-with-dependencies.jar:?]
at org.irods.jargon.core.connection.IRODSMidLevelProtocol.irodsFunction(IRODSMidLevelProtocol.java:410) ~[nfsrods-1.0.0-jar-with-dependencies.jar:?]
at org.irods.jargon.core.pub.IRODSFileSystemAOImpl.renameFile(IRODSFileSystemAOImpl.java:1205) ~[nfsrods-1.0.0-jar-with-dependencies.jar:?]
at org.irods.nfsrods.vfs.IRODSVirtualFileSystem.move(IRODSVirtualFileSystem.java:1051) ~[nfsrods-1.0.0-jar-with-dependencies.jar:?]
... 11 more
yes it may be a last mile issue on the packing instruction. I'll try and look tonight to be sure that flag is propagated all the way down
On Tue, Aug 18, 2020 at 4:55 PM Kory Draughn notifications@github.com wrote:
I tried setting the force flag to true on renameFile and mv still failed. I also tried using mv -f, but the result was the same.
I can see that the boolean value is correct deep in Jargon, but I'm not sure if it is making it to the iRODS server. The iRODS server log does not contain any messages (success or failure) following the operation either. NFSRODS log
2020-08-18 16:45:19.545 DEBUG Thread-74 [IRODSVirtualFileSystem] - move - Renaming data object from [/tempZone/home/kory/foo] to [/tempZone/home/kory/bar] ... 2020-08-18 16:45:19.545 INFO Thread-74 [IRODSFileSystemAOImpl] - renaming file:/tempZone/home/kory/foo 2020-08-18 16:45:19.545 INFO Thread-74 [IRODSFileSystemAOImpl] - to:/tempZone/home/kory/bar 2020-08-18 16:45:19.545 INFO Thread-74 [IRODSFileSystemAOImpl] - force:true 2020-08-18 16:45:19.545 INFO Thread-74 [IRODSFileImpl] - isFile() for path:/tempZone/home/kory/foo 2020-08-18 16:45:19.545 INFO Thread-74 [IRODSFileSystemAOImpl] - getObjStat(final String irodsAbsolutePath) 2020-08-18 16:45:19.545 INFO Thread-74 [CollectionAndDataObjectListAndSearchAOImpl] - retrieveObjectStatForPathWithHeuristicPathGuessing() 2020-08-18 16:45:19.548 INFO Thread-74 [CollectionListingUtils] - ObjStat [absolutePath=/tempZone/home/kory/foo, objectPath=, objectType=DATA_OBJECT, dataId=10019, checksum=, ownerName=kory, ownerZone=tempZone, objSize=13, createdAt=Tue Aug 18 16:38:07 EDT 2020, modifiedAt=Tue Aug 18 16:38:08 EDT 2020, specColType=NORMAL, collectionPath=, cacheDir=, cacheDirty=false, replNumber =0, standInGeneratedObjStat=false] 2020-08-18 16:45:19.563 INFO Thread-74 [IRODSFileImpl] - closing irodsFile:/tempZone/home/kory/bar 2020-08-18 16:45:19.563 INFO Thread-74 [IRODSFileImpl] - file is not open, silently ignore 2020-08-18 16:45:19.563 INFO Thread-74 [IRODSFileImpl] - closing irodsFile:/tempZone/home/kory/foo 2020-08-18 16:45:19.563 INFO Thread-74 [IRODSFileImpl] - file is not open, silently ignore 2020-08-18 16:45:19.563 ERROR Thread-74 [IRODSVirtualFileSystem] - Attempt to overwrite file without force flag 2020-08-18 16:45:19.563 ERROR Thread-74 [NFSServerV41] - Unhandled exception: java.io.IOException: org.irods.jargon.core.exception.JargonFileOrCollAlreadyExistsException: Attempt to overwrite file without force flag at org.irods.nfsrods.vfs.IRODSVirtualFileSystem.move(IRODSVirtualFileSystem.java:1069) ~[nfsrods-1.0.0-jar-with-dependencies.jar:?] at org.dcache.nfs.vfs.PseudoFs.move(PseudoFs.java:233) ~[nfsrods-1.0.0-jar-with-dependencies.jar:?] at org.dcache.nfs.v4.OperationRENAME.process(OperationRENAME.java:83) ~[nfsrods-1.0.0-jar-with-dependencies.jar:?] at org.dcache.nfs.v4.NFSServerV41.NFSPROC4_COMPOUND_4(NFSServerV41.java:204) ~[nfsrods-1.0.0-jar-with-dependencies.jar:?] at org.dcache.nfs.v4.xdr.nfs4_prot_NFS4_PROGRAM_ServerStub.dispatchOncRpcCall(nfs4_prot_NFS4_PROGRAM_ServerStub.java:48) ~[nfsrods-1.0.0-jar-with-dependencies.jar:?] at org.dcache.oncrpc4j.rpc.RpcDispatcher$1.lambda$run$0(RpcDispatcher.java:100) ~[nfsrods-1.0.0-jar-with-dependencies.jar:?] at java.security.AccessController.doPrivileged(Native Method) ~[?:1.8.0_265] at javax.security.auth.Subject.doAs(Subject.java:422) ~[?:1.8.0_265] at org.dcache.oncrpc4j.rpc.RpcDispatcher$1.run(RpcDispatcher.java:99) ~[nfsrods-1.0.0-jar-with-dependencies.jar:?] at org.glassfish.grizzly.threadpool.AbstractThreadPool$Worker.doWork(AbstractThreadPool.java:593) ~[nfsrods-1.0.0-jar-with-dependencies.jar:?] at org.glassfish.grizzly.threadpool.AbstractThreadPool$Worker.run(AbstractThreadPool.java:573) ~[nfsrods-1.0.0-jar-with-dependencies.jar:?] at java.lang.Thread.run(Thread.java:748) [?:1.8.0_265] Caused by: org.irods.jargon.core.exception.JargonFileOrCollAlreadyExistsException: Attempt to overwrite file without force flag at org.irods.jargon.core.connection.IRODSErrorScanner.checkSpecificCodesAndThrowIfExceptionLocated(IRODSErrorScanner.java:142) ~[nfsrods-1.0.0-jar-with-dependencies.jar:?] at org.irods.jargon.core.connection.IRODSErrorScanner.inspectAndThrowIfNeeded(IRODSErrorScanner.java:115) ~[nfsrods-1.0.0-jar-with-dependencies.jar:?] at org.irods.jargon.core.connection.IRODSMidLevelProtocol.processMessageInfoLessThanZero(IRODSMidLevelProtocol.java:1399) ~[nfsrods-1.0.0-jar-with-dependencies.jar:?] at org.irods.jargon.core.connection.IRODSMidLevelProtocol.readMessage(IRODSMidLevelProtocol.java:903) ~[nfsrods-1.0.0-jar-with-dependencies.jar:?] at org.irods.jargon.core.connection.IRODSMidLevelProtocol.readMessage(IRODSMidLevelProtocol.java:871) ~[nfsrods-1.0.0-jar-with-dependencies.jar:?] at org.irods.jargon.core.connection.IRODSMidLevelProtocol.irodsFunction(IRODSMidLevelProtocol.java:284) ~[nfsrods-1.0.0-jar-with-dependencies.jar:?] at org.irods.jargon.core.connection.IRODSMidLevelProtocol.irodsFunction(IRODSMidLevelProtocol.java:410) ~[nfsrods-1.0.0-jar-with-dependencies.jar:?] at org.irods.jargon.core.pub.IRODSFileSystemAOImpl.renameFile(IRODSFileSystemAOImpl.java:1205) ~[nfsrods-1.0.0-jar-with-dependencies.jar:?] at org.irods.nfsrods.vfs.IRODSVirtualFileSystem.move(IRODSVirtualFileSystem.java:1051) ~[nfsrods-1.0.0-jar-with-dependencies.jar:?] ... 11 more
— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/irods/irods_client_nfsrods/issues/92#issuecomment-675715555, or unsubscribe https://github.com/notifications/unsubscribe-auth/AAIL4LLYL3HUQ3IA6RVI2MDSBLTD3ANCNFSM4OEJQDLA .
If we attempt to use
mv
on an nfsrods mount to overwrite a file, we get an I/O error.The same is true if we use
mv -f
.