Avoiding excessive error dialogs during copy/move

Question

I use vifm to move files between different filesystems alot (for example, to move files to my NAS). Since the filesystems support different features, I get many error dialogs to the effect of ...operation not supported. The copy/move operation halts until I dismiss the dialog.

Is there a way to have all these messages displayed as a single dialog at the end as opposed to a message for each file?

I've tried:

1. :move %i: This renames a selected file to %i.
2. :move &: This puts the operation in the background, but still displays a dialog for each file being moved.
3. :move %"f %"D %i: This is an error: Too many file names (3/1)

Answer 1

There is no syntax that affects error reporting. However, error dialog should present "ignore all" option in such cases so that you only need to react to the error once.

Maybe "operation not supported" errors shouldn't even be reported, it's not an error situation, just an attempt to do thing that can't work.

Maybe provide an example where you get too many errors with the following information:

1. Source filesystem
2. Destination filesystem
3. How many entries in a view are being processed by the command
4. Version of Vifm (I remember making "ignore all" being applied to the whole operation rather than each file in a selection)
5. Error message (text copy from terminal or a screenshot) to know for sure what part of the code emits it

Comments

I've tested this with two source filesystems:

1. An NTFS filesystem mounted with ntfs-3g under ubuntu
2. An ext4 filesystem mounted under ubuntu.

The destination filesystem is an ext4 filesystem mounted under debian and exposed as a network share with samba.

The version of vifm is 12.0. It's the default package from ubuntu 23.10.

The number of entries in the selection doesn't seem to change the behavior. I get the same result whether it's one entry or a dozen.

If I use the default :copy command, I get a dialog for each file in the selection, with no option to ignore future issues.

If I put the job in the background with :copy & I get periodic dialogs with different subsets of files in the selection. These dialogs do have a message that Ctrl-C can ignore future dialogs.

Sample modal text from :copy

Background Process Error

cp: preserving times for '/home/xxx/FS/scratch/a': Operation not permitted

Press Return to continue 

Sample modal text from :copy &

Background Process Error

cp: preserving times for '/home/xxx/FS/scratch/a': Operation not permitted
cp: preserving times for '/home/xxx/FS/scratch/b': Operation not permitted
cp: preserving times for '/home/xxx/FS/scratch/c': Operation not permitted
cp: preserving times for '/home/xxx/FS/scratch/d': Operation not permitted
cp: preserving times for '/home/xxx/FS/scratch/e': Operation not permitted
cp: preserving times for '/home/xxx/FS/scratch/f': Operation not permitted

Press Return to continue or Ctrl-C to skip its future error messages

---

Thanks for the details. Have you tried enabling 'syscalls' option? With your current configuration Vifm calls cp to copy files and has little control over error reporting (although there is a room for improvement for ignoring errors).

---

I gave the syscalls option a shot this morning and it improves the scenario a bit. It lets me only respond to the first error and ignore all for other files in the selection:

Error while Copying

 ~/FS/scratch/a: Failed to setup file permissions

[r]etry/[i]gnore/[I]gnore for all/[a]bort

This is (again) copying from an NTFS filesystem to a samba-exposed ext4 filesystem. The 'Failed to setup file permissions' message looks expected, since samba will be saving the file with a different owner and group. It's interesting that it's a different error from using the external commands.

After the operation it then summarizes all the messages for the entire batch with a modal similar to the one from my previous comment.

This works without having to remember to put the job in the background. (I'm not sure I want to use background jobs anyway. I'm afraid I'll select a file that's already queued for a separate job).

Thanks for the help. This has definitely improved my setup. I agree with your statement above that it could be improved, but I don't want to ask for anything specific because I don't know what other workflows I'd be breaking :)

---

It's interesting that it's a different error from using the external commands.

It's probably the same, the text is different because it a string in Vifm's code instead of system error (which should actually be included as well and is inconsistently included only in the summary message).

If filesystem driver responds with "Operation not permitted" error code, it's hard to know when it's safe to ignore it (might be an actual permission error due to a concurrent process updating the same files, for example).

---

I just wanted to say thanks again for the help. vifm definitely makes many things much easier for me, and it's one of the best vi(m)-influenced projects out there -- particularly in the way it is extensible with existing shell tools.

If filesystem driver responds with "Operation not permitted" error
code, it's hard to know when it's safe to ignore it (might be an
actual permission error due to a concurrent process updating the same
files, for example).

That's a good point and I completely agree. I expect this has the same implications for the prompting behavior. If an error occurs it is definitely within reason that the user would want to cancel the rest of the job.

The best approach for me may be a custom script that filters out a subset of operation not permitted errors when the target is a samba filesystem.