Exist: Directly moving files locked by another user is prevented, but moving a collection ignores the lock

[tremms18]

I found that I am prevented from moving a file that is locked by another user if I try to move it by itself. If I go to the same file's parent collection and move the collection, I am able to move the file via the collection.

[adamretter]

It looks like this effects the WebDAV, XML-RPC and XML:DB API's.

It seems that UserLocks are only checked in NativeBroker#moveResource and not NativeBroker#moveCollection.

moveResource looks has these lines:

final Account docUser = doc.getUserLock(transaction);
if(docUser != null) {
    if(!(getCurrentSubject().getName()).equals(docUser.getName())) {
        throw new PermissionDeniedException("Cannot move '" + doc.getFileURI() + " because is locked by getUser() '" + docUser.getName() + "'");
    }
}

It seems to be that we should be consistent in the least, i.e. either:

1. Ignore the User Lock completely (which would seem silly)
2. Respect the User Lock in both moveResource and moveCollection

[adamretter]

@dizzzz As this effects the WebDAV API, what do you think?

[dizzzz]

I Will have a look later today....

[dizzzz]

Pooh, isn't a (kind of) fundamental issue? I realise that for this operation it must be recursively checked if somewhere a lock is active (webdav is not special in this I guess, except that propound must report it too).

I wonder why we did not think of this before, I mean, It does not sound like a corner case to me.....

[adamretter]

@dizzzz Yeah to solve we have to either introduce a lock table or recursively search the sub-collection hierarchy for locked documents at Collection move time.

[dizzzz]

A locktable... Would be very helpful! I have been thinking to make one , when I implemented the WebDAV stuff. The way how locktokens are stored... Is sub optimal.

A locktable would be awesome and fast!

[shabanovd]

@adamretter @dizzzz @wolfgangmm there is metadata storage, can it be useful for that? also, move current resource metadata will improve performance a lot.

[adamretter]

@shabanovd I am not really sure what you are proposing?

[dizzzz]

probably https://github.com/eXist-db/exist/tree/develop/extensions/metadata ...
https://github.com/eXist-db/exist/blob/develop/extensions/metadata/sleepycat/src/main/java/org/exist/storage/md/MetaDataImpl.java

[shabanovd]

@adamretter, yeap, @dizzzz is right. Metadata storage (extension) design to store key-value pair per resource (collections, xml & binary documents). It have simple methods to set & get that pairs. There is also backup integration.

[adamretter]

@shabanovd @dizzzz Sure I understood Dmitriy mean the metadata extension, but I don't see how that is relevant here?

[dizzzz]

My impression that he suggest not to built a separate lock-table, but to use this extension in stead; also it could be used to offload the current dbx files with (other) document meta-data.

[adamretter]

Hmm a lock table would be core to the database so I don't think an extension is a good idea. Also the lock-table does not need persistent storage.

[shabanovd]

@adamretter why metadata storage can't become core feature?

[adamretter]

@shabanovd It uses an external data-store, IMHO this doesn't make it easy in future to integrate transactions etc across both stores. Also, I don't see that the lock table needs to be persistent and so this seems like a lot of overhead for something simple.
The lock table will need to be fast though, so something like an in-memory skip list is probably enough.

[dizzzz]

i tend to agree with @adamretter here;

[shabanovd]

@adamretter "I don't see that the lock table needs to be persistent" ... hmmm, are you 100% sure on that?

[adamretter]

@shabanovd Nope ;-) So... why do you think we need to be able to persist it?

[shabanovd]

@adamretter because production server upgrade must not be visible for end user. All locks must persistent.

Also, eXist's metadata operations very heavy and must be optimized, making metadata storage core feature is good step for that too, IMHO

[dizzzz]

Ah I missed something crucial ; until now I have always been convinced that locks should be persistent (It adds additional complexity for sure).

But..... I need to think about the rationale about this; would it hurt if a lock is gone after server reset? not sure , @wolfgangmm ? @ljo ?

[dizzzz]

My initial idea is and was to add an new btree thingy to exist for metadata; all logic is their already no?

[shabanovd]

@dizzzz @adamretter @wolfgangmm @ljo Metadata storage is not just "add another btree", but question of infrastructure: backup/restore, handle copy, move, remove operations. Right now, metadata storage implemented with sleepycat storage, and it modular design allow to implement storage based on eXist's btree. Rest in place already.

[caseydawsonjordan]

Just wanted to chime in and add that the existing behavior of locks
persisting across restarts is pretty important to maintain. Users may lock
(checkout) files, and expect those locks to be maintained through restarts,
upgrades etc. For systems doing document management this is pretty crucial
behavior. Thanks!

On Sun, Mar 27, 2016 at 5:42 PM Dmitriy Shabanov [email protected]
wrote:

@dizzzz https://github.com/dizzzz @adamretter
https://github.com/adamretter @wolfgangmm
https://github.com/wolfgangmm @ljo https://github.com/ljo Metadata
storage is not just "add another btree", but question of infrastructure:
backup/restore, handle copy, move, remove operations. Right now, metadata
storage implemented with sleepycat storage, and it modular design allow to
implement storage based on eXist's btree. Rest in place already.

—
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub
https://github.com/eXist-db/exist/issues/954#issuecomment-202150717