https://bugs.kde.org/show_bug.cgi?id=393397
--- Comment #18 from Andrius Štikonas <andr...@stikonas.eu> --- (In reply to Teddy from comment #14) > (In reply to Andrius Štikonas from comment #13) > > (In reply to Teddy from comment #12) > > > (In reply to Andrius Štikonas from comment #11) > > > > (In reply to Teddy from comment #10) > > > > > When running Deactivate doen't refresh either. > > > > > > > > Oh yeah... This is actually simply not implemented yet. So it is more > > > > of a > > > > feature request than a bug. > > > > > > Then just refresh. All partition manager for Microsoft Windows do that > > > automatically, always. > > > > It's better to just rescan what's necessary, not everything. Note that > > refreshing also means clearing all pending operations. > > Avoiding automatic refresh causes problems, because enables option in the > user interface which shouldn't be there. > For example, follow this steps: > > 1) Select luks volume (sdc2) > Decrypt > Enter proper passphrase > > 2) Select again same volume (sdc2) > Deactivate > ERROR: "The encrypted file > system on partition /dev/sdc2 could not be locked.". Details>> doesn't show > why it happened (see bug #393393) > > This happens, because it displays the option "Deactivate", when shouldn't be > available until you Deactivate Volume Group on new created device, which > isn't visible until you refresh. > > And if you want to refresh, you have to cancel the queue anyway, so it > doesn't make sense to overlap both things. You are mixing operations that > can be queued (create new simple partition), with others that take effect > immediately, like unlocking/re-locking luks volumes. > > The User Interface must be consistent at all times, so a way to mix both > types of operations has to be found. Hmm, but Volume groups shouldn't be activated by just unlocking LUKS volume? It only runs "crypsetup open", so I don't understand why your Volume group is active? Maybe I'll have to test to see if I can reproduce failure to lock.(In reply to Teddy from comment #14) > (In reply to Andrius Štikonas from comment #13) > > (In reply to Teddy from comment #12) > > > (In reply to Andrius Štikonas from comment #11) > > > > (In reply to Teddy from comment #10) > > > > > When running Deactivate doen't refresh either. > > > > > > > > Oh yeah... This is actually simply not implemented yet. So it is more > > > > of a > > > > feature request than a bug. > > > > > > Then just refresh. All partition manager for Microsoft Windows do that > > > automatically, always. > > > > It's better to just rescan what's necessary, not everything. Note that > > refreshing also means clearing all pending operations. > > Avoiding automatic refresh causes problems, because enables option in the > user interface which shouldn't be there. > For example, follow this steps: > > 1) Select luks volume (sdc2) > Decrypt > Enter proper passphrase > > 2) Select again same volume (sdc2) > Deactivate > ERROR: "The encrypted file > system on partition /dev/sdc2 could not be locked.". Details>> doesn't show > why it happened (see bug #393393) > > This happens, because it displays the option "Deactivate", when shouldn't be > available until you Deactivate Volume Group on new created device, which > isn't visible until you refresh. > > And if you want to refresh, you have to cancel the queue anyway, so it > doesn't make sense to overlap both things. You are mixing operations that > can be queued (create new simple partition), with others that take effect > immediately, like unlocking/re-locking luks volumes. > > The User Interface must be consistent at all times, so a way to mix both > types of operations has to be found. Hmm, but Volume groups shouldn't be activated by just unlocking LUKS volume? It only runs "crypsetup open", so I don't understand why your Volume group is active? Maybe I'll have to test to see if I can reproduce failure to lock. -- You are receiving this mail because: You are watching all bug changes.
