files progress dialog minimized

[Carottinger]

Sometime when I copy files interactively using io.elementary.files (either local to to smb/ftp) the copy dialog disappers. When I manage to restore it it is just a little white box so I can't acctually see what's happening or if there are any problems. The file icon in the plank show some (dark) progess bar but the dialog box is just empty.

[jeremypw]

If you can determine under what circumstances it disappears that would help (i.e. what were you doing just before it disappears, if anything). If the issue can be reliably reproduced it is easier to fix. If it is truly random (which is rare) it may be some kind of race condition. Also please confirm what version you are using (e.g. juno stable, juno daily or self built on something else)

[ghost]

I noticed something similar that causes Files to show the dark progress bar which appears to be stuck. Closing and opening Files doesn't seem to clear the issue. These are steps I took to recreate problem but only works sometimes so can't guarantee will work each time.

• Right click on a file, say in "Downloads" folder and compress it to .7z
• Click the .7z file and usually the Downloads folder will reopen as a new tab in Files.
• Delete the .7z File in the new opened Downloads tab.
• Return to the first Downloads tab and press the delete key on the .7z file that's still there.
• An error box will appear (Cannot move file to trash. Try to delete it?). Press cancel then go to Trash and empty Trash.
• If lucky or unlucky a dark progress bar will remain on the Files icon in plank.

From this point if you try to redo those steps a second or third time sometimes compressing a file will make the compressed file invisible. Using the latest version of Juno, with latest updates.

[jeremypw]

There seems to be two issues here:

• The copy dialog disappears
• The dock icon shows a dark progress bar inappropriately

[Carottinger]

1. This is how the progress bar lloks like I could not find any "appropriate" message in the syslog

2. It's hard to tell if the copy (or move) operation actually works out and if the progress shown in the dock icon is correct but I guess then I would seen something happening (with the files and the progress bar). Once it gets stuck it stays there (the popup and the progess bar). I usually kill the io.elementary.files to be able to cop/move the (files (mostly videos, sometimes internal only, sometimes inter to ftp server). Also the "close all windows" does not affect anything - just killing the app.

[jeremypw]

If this has started happening recently I guess it could be a regression due to https://github.com/elementary/files/commit/36cd09c6934dce0f399f62c39c962909b380d89d if the operation seems blocked when it isn't for some reason. This is in version 4.1.9 and later. Is this more likely to happen with a large file (e.g. a video) over a slow link?

[jeremypw]

The image shown above is actually the progress window rather than the progress bar itself. The progress window, when visible, should contain one or more progressbar widgets each representing one file operation. The progress bar widget is destroyed when the operation is finished or cancelled. The progress window should be hidden when all its children have been destroyed but is not actually destroyed itself. @Carottinger how did you manage to restore it? If it is empty then it means all the file operations have either finished or were cancelled or timed out either by user action or a fatal error occurred. If the Files window is not focused when the file operation ends you should get a notification but this will not happen if you have the Files window focused. Looks like we need to ensure that if the file operation ends for any reason other than success then the user is notifiied of the reason.

[Carottinger]

If this has started happening recently I guess it could be a regression due to 36cd09c if the operation seems blocked when it isn't for some reason. This is in version 4.1.9 and later. Is this more likely to happen with a large file (e.g. a video) over a slow link?

Recently I see it more often, eg. every 20-50 copy operations (more files). These are mostly large (video) files over a eff. 10 MB/s WLAN (5GHz) Link

[Carottinger]

The image shown above is actually the progress window rather than the progress bar itself. That's right. I am mainly concerned with the popup window rather than the icon bar. The progress window, when visible, should contain one or more progressbar widgets each representing one file operation. The progress bar widget is destroyed when the operation is finished or cancelled. The progress window should be hidden when all its children have been destroyed but is not actually destroyed itself. @Carottinger how did you manage to restore it?

I did not restore it, it started like this after the first copy operation and even if I launch a second copy it stays like that.

I can focus on that using the "show copy dialogue" from the dock icon context menu - so I guess it is assumed that a progress is still ongoing (I can't see this menu item when no copy operation is ongoing).

If it is empty then it means all the file operations have either finished or were cancelled or timed out either by user action or a fatal error occurred. If the Files window is not focused when the file operation ends you should get a notification but this will not happen if you have the Files window focused. Looks like we need to ensure that if the file operation ends for any reason other than success then the user is notifiied of the reason.

Well I am not sure that all operations have really ended - may be they are in a somewhat different state, at least the context menu item to show the dialogue (if the menu isn't outdated but not refreshed properly) is "still there".

[jeremypw]

If it happens every 20 - 50 copy operations with no obvious feature identifying those operations that cause the problem and allow it to be reproduced it is probably due to a rare race condition - which are harder to diagnose :-( We'll just have to study the code. My guess is that the window is somehow missing the signal that tells it that the operation has ended and the progressbar destroyed so it stays visible while empty.

The progress dialog does not have any influence on the file operation itself so problems with it should not cause any problem with the operation. If you look at the target directory in ListView then you should see the size of the copied file and whether it is still changing.

[Carottinger]

Whenever this happens the copy performs "normal" an the mini-popup can be moved (no resize). When the copying is finished the popup disappears and the next copy task may perform with a properly filled popup window.

[jeremypw]

Trying out the sequence given above I notice that there is another issue: When you delete a file, any open tab that is showing that file should automatically update to remove that file item. It should not therefore be possible to delete the same file twice. I can confirm that it is possible to end up with a persistent progress bar on the Plank icon using this sequence. Moreover, when in this state, the icon context menu contains the "Show Copy Dialog" and "Cancel all in-progress actions" options (which have no effect if pressed and do not disappear). Moreover, when the icon is clicked Files opens but does not restore tabs - rather it tries to open the file that was the subject of the delete operation (which does not exist any longer) indicating that the dock is passing it as a parameter to Files when it launches it.

[jeremypw]

Ther automatic refresh failure seems to happen particularly after clicking on a compressed file, causing a new tab to open (if FIles has been set as the default app for compressed files of that type). If you set "Archive Manager" as the default app then this problem can be avoided. I am not sure why Archive Manager is not automatically the default app rather than Files as it is the more logical choice.

Nevertheless, Files should not be screwed up in this way,

[jeremypw]

The reason why a new tab opens if you click on an archive (any other non-folder file) when Files is set as the default app for that type is that Files automatically opens the parent folder when asked to open a non-folder file. This was implemented to enable, for example, setting a bookmark for a non-folder file.

[jeremypw]

I do not think it is an issue with Files if the default app is incorrectly set for any reason.

[jeremypw]

The problem with deleting from duplicate tab opened as a result of clicking on a non-folder file item is due to the fact that the tabs do not share a directory object as they normal would since they were generated from different uris. This means that the file-deleted signal is not propagated to both tabs. Am working on a fix for this.

[Carottinger]

I did not have the problem for a while but today I observed a first transfer which had some interactive Popup (merge folders) followed by an empty dialog (running in background). During the first transfer I started a second one (mostly ftp to local win server - more robust and faster than smb to win10) without interaction and (only) this transfer showed up in the transfer dialog. After the second (smaller9 transfer was finished the dialog returned to "empty". After I killed to whole "io.elementary.files" Process (from gnome.system-monitor) the empty dialog was gone (it stayed open and empty after the first transfer had finished) and after "files" restart it worked normal on further transfers.

[Carottinger]

Today it happened again (first empty, than add. transfer shows up than empty again while transfer still pending

[jeremypw]

I have noticed that after a file transfer, the progress bar that is shown on top of the Plank emblem does not always disappear. If this happens, then open gnome-system-monitor and look at the background processes. You will probably find io.elementary.files there. You need to kill this to reset Files for another transfer. I will try to find time to investigate this.

[jeremypw]

It is possible that this is an unintended consequence of 36cd09c6934dce0f399f62c39c962909b380d89d. Maybe the progress window is now closing when it shouldn't rather than staying open when it should have closed (!)

[jeremypw]

@Carottinger There is a PR that might fix this (#1154). If you are able to test this to see whether it solves your problem it would be helpful (you would need to be familiar with compiling and installing from source code though).