qvm-copy-to-vm behaviour with existing files

[kirill9000]

qvm-copy-to-vm fails if some file already exists on destination VM. But when copying a directory, I think it would be better if it transferred files that are not present on destination VM (while skipping already existing of course) rather than fail.

[bnvk]

I think it would be better if it transferred files that are not present on destination VM (while skipping already existing of course) rather than fail.

This does sound like an improvement, IMO but unsure about feasibility. Hey @marmarek is doing this sort of thing possible?

[bnvk]

I think it would be better if it transferred files that are not present on destination VM (while skipping already existing of course) rather than fail.

This does sound like an improvement, IMO but unsure about feasibility. Hey @marmarek is doing this sort of thing possible?

[marmarek]

This does sound like an improvement, IMO but unsure about feasibility. Hey @marmarek is doing this sort of thing possible?

Technically it is possible (quite trivial). But I'm afraid of some reporting here. For example if user have some document he/she want to send via email, it requires copying it into email VM. If there was already file identically named (for example its previous version), such skipping instead of failing will most likely mean the user will send old version of the document without noticing it.

[marmarek]

This does sound like an improvement, IMO but unsure about feasibility. Hey @marmarek is doing this sort of thing possible?

Technically it is possible (quite trivial). But I'm afraid of some reporting here. For example if user have some document he/she want to send via email, it requires copying it into email VM. If there was already file identically named (for example its previous version), such skipping instead of failing will most likely mean the user will send old version of the document without noticing it.

[andrewdavidwong]

If there was already file identically named (for example its previous version), such skipping instead of failing will most likely mean the user will send old version of the document without noticing it.

Very good point. Expected user result would probably be something like:

1. file.txt already exists in destvm
2. [user@sourcevm]$ qvm-copy-to-vm destvm file.txt
3. file.txt and file (from sourcevm).txt now both exist in destvm

This would mirror the way most OSes handle copy/pasting a file into the same folder as the original. Usually you end up with the original file.txt and the copy is named file (1).txt or copy of file.txt. (But of course qvm-copy-to-vm might deliver a file with the same name but different content, so we don't want to just assume it's a "copy.")

[andrewdavidwong]

If there was already file identically named (for example its previous version), such skipping instead of failing will most likely mean the user will send old version of the document without noticing it.

Very good point. Expected user result would probably be something like:

1. file.txt already exists in destvm
2. [user@sourcevm]$ qvm-copy-to-vm destvm file.txt
3. file.txt and file (from sourcevm).txt now both exist in destvm

This would mirror the way most OSes handle copy/pasting a file into the same folder as the original. Usually you end up with the original file.txt and the copy is named file (1).txt or copy of file.txt. (But of course qvm-copy-to-vm might deliver a file with the same name but different content, so we don't want to just assume it's a "copy.")

[marmarek]

The (from sourcevm) addition doesn't scale well - what if that file exists too? Maybe simply use numbers: file.txt, file (1).txt, file (2).txt etc.
But I'm still not so sure is it a good idea at all. Sooner or later it will lead to using wrong file.
Maybe better have some GUI window asking to skip/replace the file in case of conflict (with default of skip)?

[marmarek]

The (from sourcevm) addition doesn't scale well - what if that file exists too? Maybe simply use numbers: file.txt, file (1).txt, file (2).txt etc.
But I'm still not so sure is it a good idea at all. Sooner or later it will lead to using wrong file.
Maybe better have some GUI window asking to skip/replace the file in case of conflict (with default of skip)?

[andrewdavidwong]

The (from sourcevm) addition doesn't scale well - what if that file exists too?

Well, I figured it would be something like:

file.txt
file (from sourcevm).txt
file (from sourcevm 1).txt
file (from sourcevm 2).txt
file (from sourcevm 3).txt

This would be in keeping with the way most conventional system seem to handle renaming copies. Personally, I dislike spaces and parentheses in filenames.

But I'm still not so sure is it a good idea at all. Sooner or later it will lead to using wrong file.

At some point it, it has to become the user's responsibility to choose the correct file. If the user wants to create n copies of a file, then the user should expect to have to choose from among n roughly homonymous files.

Maybe better have some GUI window asking to skip/replace the file in case of conflict (with default of skip)?

That might be better. It would make the choice more explicit to the user and alert the user to the fact that there already exists a homonymous file at the destination. However, it would also add to the (mental and physical) overhead of performing the copy operation.

[andrewdavidwong]

The (from sourcevm) addition doesn't scale well - what if that file exists too?

Well, I figured it would be something like:

file.txt
file (from sourcevm).txt
file (from sourcevm 1).txt
file (from sourcevm 2).txt
file (from sourcevm 3).txt

This would be in keeping with the way most conventional system seem to handle renaming copies. Personally, I dislike spaces and parentheses in filenames.

But I'm still not so sure is it a good idea at all. Sooner or later it will lead to using wrong file.

At some point it, it has to become the user's responsibility to choose the correct file. If the user wants to create n copies of a file, then the user should expect to have to choose from among n roughly homonymous files.

Maybe better have some GUI window asking to skip/replace the file in case of conflict (with default of skip)?

That might be better. It would make the choice more explicit to the user and alert the user to the fact that there already exists a homonymous file at the destination. However, it would also add to the (mental and physical) overhead of performing the copy operation.