irods / irods_client_nfsrods

An nfs4j Virtual File System implementation supporting the iRODS Data Grid
BSD 3-Clause "New" or "Revised" License
8 stars 9 forks source link

IOException when attempting to overwrite a file #92

Closed anderbubble closed 4 years ago

anderbubble commented 4 years ago

If we attempt to use mv on an nfsrods mount to overwrite a file, we get an I/O error.

$ cp /pl/archive/ics/random-file /pl/archive/ics/jandrewshanna/random-file
$ ls /pl/archive/ics/jandrewshanna
jandrewshanna_AA.tar.gz  random-file
$ mv /pl/archive/ics/random-file /pl/archive/ics/jandrewshanna/random-file
mv: cannot move ‘/pl/archive/ics/random-file’ to ‘/pl/archive/ics/jandrewshanna/random-file’: Remote I/O error

The same is true if we use mv -f.

[lesh2786@blogin-ics2 ~]$ mv -f /pl/archive/ics/random-file /pl/archive/ics/jandrewshanna/random-file
mv: cannot move ‘/pl/archive/ics/random-file’ to ‘/pl/archive/ics/jandrewshanna/random-file’: Remote I/O error
anderbubble commented 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
trel commented 4 years ago

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?

michael-conway commented 4 years ago

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.

trel commented 4 years ago

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.

anderbubble commented 4 years ago

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
anderbubble commented 4 years ago

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.

trel commented 4 years ago

Ah, very good - didn't realize it doesn't get conveyed to the filesystem.

Okay, so option 2 it is. Thanks.

michael-conway commented 4 years ago

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.

trel commented 4 years ago

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?

anderbubble commented 4 years ago

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.

trel commented 4 years ago

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?

trel commented 4 years ago

Alternately, NFSRODS just goes with option 2 (always uses -f, behaves like POSIX) and offers no configurability on this point.

anderbubble commented 4 years ago

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.

trel commented 4 years ago

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?

korydraughn commented 4 years ago

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.

anderbubble commented 4 years ago

What's the state of this? Any chance of seeing a fix in an upcoming release?

korydraughn commented 4 years ago

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.

korydraughn commented 4 years ago

@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.

michael-conway commented 4 years ago

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 .

korydraughn commented 4 years ago

possibly. i'll try it out and see what happens.

michael-conway commented 4 years ago

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 .

korydraughn commented 4 years ago

That would certainly speed things up. Maybe we can handle this issue after the working group meeting. I imagine it shouldn't take long.

michael-conway commented 4 years ago

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 .

michael-conway commented 4 years ago

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 .

korydraughn commented 4 years ago

Excellent!

korydraughn commented 4 years ago

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
michael-conway commented 4 years ago

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 .