search

freedomofpress / securedrop-client

a Qt-based GUI for SecureDrop journalists 📰🗞️
GNU Affero General Public License v3.0
41 stars 40 forks source link

Dialog displays a system error (possibly export-related) #1368

Open gonzalo-bulnes opened 2 years ago

gonzalo-bulnes commented 2 years ago

Observed

An sd-app dialog seems to display a system error.

qfile-unpacker: Fatal error: Cannot umount incoming directory (error type: invalid argument)

Reported by @ninavizz May be related to #554

Expected

No errors are directly displayed to the user, instead they're handled and copy is adjusted for end-user audiences.

Steps to reproduce

Unclear

eloquence commented 2 years ago

Per @conorsch

that error can occur if qvm-copy is used simultaneously with the same target VM.

It shouldn't be possible to kick off an export operation when one is in flight due to the modal dialog. @ninavizz speculated that she may have removed a USB drive prematurely.

ninavizz commented 2 years ago

@eloquence I was taking screenshots and transferring screenshots, while doing export things. Could that perhaps have been a part of it, or are you thinking just qvm-copy to the export vm?

eloquence commented 2 years ago

If you ran multiple inter-VM copy operations manually for the screenshots, that could very well have been the cause.

sssoleileraaa commented 2 years ago

some more details from @conorsch (just to contribute some more context to what @eloquence wrote in https://github.com/freedomofpress/securedrop-client/issues/1368#issuecomment-988481877)

that error can occur if qvm-copy is used simultaneously with the same target VM. based on the screenshot, the src files were named differently, but the target VM was the same. if the src files were also named the same, then there'd be an additional error message. screenshot to illustrate STR qvm-copy-only-serially

eloquence commented 2 years ago

I just encountered this issue twice during QA of https://github.com/freedomofpress/securedrop-workstation/pull/751. Specifically, what I did is: 1) Initialize a fresh .securedrop_client directory with only the config.json containing the submission key fingerprint 2) Launch the client in offline mode 3) From there, log in and wait for it to sync 4) While it's syncing (specifically downloading replies), tried to download some files

During this, I encountered the error twice. After the sync finished, I could no longer reproduce the error.

This might suggest some concurrency issues between downloads and syncs.

To be clear, I have no evidence that this is a recent regression.