copyCollection creates orphaned documents when target collection name is the same as source

[caseydawsonjordan]

To reproduce:

1.) Create a collection with documents in it. 2.) Copy that collection to a seperate location 3.) Copy it back over the original 4.) Take a backup and see all the original files are now in the lost_and_found

IHMO the correct solution to this is to throw an exception when the target collection exists to prevent data loss. The same should be applied to moveCollection, which will simply delete the target if it exists. Without an exception being thrown this creates a situation for data loss to occur very easily without warning.

[dizzzz]

It is all about WebDAV? That is: by calling the WebDAV methods? Or is it in General?

[shabanovd]

This behavior of eXist's core. I think that exception is normal, or better to say, expecting reaction.

@adamretter @wolfgangmm , what do you think?

[dizzzz]

I have been thinking a bit more on this: For me, this kind of protection should be on application level, not on the 'core'. I do not want this protection out of the box, my move command....... should just be moving data.

[caseydawsonjordan]

Dannes I have a very hard time understanding why that would be preferable.

1.) This isn't how any other system operates, especially unix. eXist is suppose to mimic unix as closely as possible...no? 2.) By leaving this logic at the application level this creates a very real possibility that developers unintentionally create a way for end users to very easily lose data. (This is already a fact with several eXist extensions). 3.) Why not have this protection built in, and then have the application layer override it if they want?...This would give the same exact amount of control, but would eliminate the possibility of unintentional data loss....

On Mon, Dec 16, 2013 at 2:45 PM, Dannes Wessels notifications@github.comwrote:

I have been thinking a bit more on this: For me, this kind of protection should be on application level, not on the 'core'. I do not want this protection out of the box, my move command....... should just be moving data.

— Reply to this email directly or view it on GitHubhttps://github.com/eXist-db/exist/issues/99#issuecomment-30693203 .

Casey Jordan easyDITA a product of Jorsek LLC "CaseyDJordan" on LinkedIn, Twitter & Facebook (585) 348 7399 easydita.com

This message is intended only for the use of the Addressee(s) and may contain information that is privileged, confidential, and/or exempt from disclosure under applicable law. If you are not the intended recipient, please be advised that any disclosure copying, distribution, or use of the information contained herein is prohibited. If you have received this communication in error, please destroy all copies of the message, whether in electronic or hard copy format, as well as attachments, and immediately contact the sender by replying to this e-mail or by phone. Thank you.

[adamretter]

Casey I agree with you. This has to be recognised as a bug in the core, of course we should never be intentionally orphaning files!

The only question is whether to either:

a) Throw an Exception at (3) if the collection already exists b) Just overwrite the collection at (3) if the collection already exists c) Something else...

My preference here would be to avoid exceptions and do (c) i.e. just one-way merge the source to the destination during the copy, this is exactly what happens on a UNIX system. e.g. given the filesystem:

/1/A/hello.txt /2/A/goodbye.txt

and given the command: "cp -r /1/A /2"

Then, /2/A ends up with both hello.txt and goodbye.txt files, any files with the same name that existed in both /1/A and /2/A would have been overwritten in /2/A by the copy.

I meant to add that, if you need protection it is up to you to check whether the collection/resource exists before doing the copy/move, just like in UNIX.

[caseydawsonjordan]

Adam,

I see the appeal to this approach. It's certainly better than the alternative. Still makes me nervous though ;) I'd prefer to have a flag which needed to be set (or two sets of methods) so that it was very clear to the developer what the function was doing at a quick glance. It would be verbose, and a bit ugly but super safe.

It's somewhat like the age old practice of creating a new alias for 'mv' and 'cp' that does some extra checking to prevent accidentally issuing a command you would regret when working too late some night...

On Mon, Dec 16, 2013 at 3:11 PM, Adam Retter notifications@github.comwrote:

Casey I agree with you. This has to be recognised as a bug in the core, of course we should never be intentionally orphaning files!

The only question is whether to either:

a) Throw an Exception at (3) if the collection already exists b) Just overwrite the collection at (3) if the collection already exists

My preference here would be to avoid exceptions and just one-way merge the source to the destination during the copy, this is exactly what happens on a UNIX system. e.g. given the filesystem:

/1/A/hello.txt /2/A/goodbye.txt

and given the command: "cp -r /1/A /2"

Then, /2/A ends up with both hello.txt and goodbye.txt files, any files with the same name that existed in both /1/A and /2/A would have been overwritten in /2/A by the copy.

— Reply to this email directly or view it on GitHubhttps://github.com/eXist-db/exist/issues/99#issuecomment-30695738 .

Casey Jordan easyDITA a product of Jorsek LLC "CaseyDJordan" on LinkedIn, Twitter & Facebook (585) 348 7399 easydita.com

This message is intended only for the use of the Addressee(s) and may contain information that is privileged, confidential, and/or exempt from disclosure under applicable law. If you are not the intended recipient, please be advised that any disclosure copying, distribution, or use of the information contained herein is prohibited. If you have received this communication in error, please destroy all copies of the message, whether in electronic or hard copy format, as well as attachments, and immediately contact the sender by replying to this e-mail or by phone. Thank you.