From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <gmazyland@gmail.com>
Received: from mail.saout.de ([127.0.0.1])
 by localhost (mail.saout.de [127.0.0.1]) (amavisd-new, port 10024)
 with ESMTP id Bc7kok2Qk4fG for <dm-crypt@saout.de>;
 Tue, 19 Mar 2013 07:23:26 +0100 (CET)
Received: from mail-ee0-f43.google.com (mail-ee0-f43.google.com [74.125.83.43])
 (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits))
 (No client certificate requested)
 by mail.saout.de (Postfix) with ESMTPS
 for <dm-crypt@saout.de>; Tue, 19 Mar 2013 07:23:25 +0100 (CET)
Received: by mail-ee0-f43.google.com with SMTP id c50so48130eek.2
 for <dm-crypt@saout.de>; Mon, 18 Mar 2013 23:23:25 -0700 (PDT)
Message-ID: <51480423.7040807@gmail.com>
Date: Tue, 19 Mar 2013 07:22:27 +0100
From: Milan Broz <gmazyland@gmail.com>
MIME-Version: 1.0
References: <CAFnMBaS_awqpi5WaR59N3Ju_9X9RAVkturUnb4K3W4-vFCpVEw@mail.gmail.com>
 <51478EC4.4020006@gmail.com>
 <CAFnMBaTah7oR=D2j=da5ZosN8y65e+sAtaTzgd4EPE+TQ_xECQ@mail.gmail.com>
In-Reply-To: <CAFnMBaTah7oR=D2j=da5ZosN8y65e+sAtaTzgd4EPE+TQ_xECQ@mail.gmail.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Subject: Re: [dm-crypt] an official way to know if the underlying device is
 gone for all supported volume formats
List-Id: <dm-crypt.saout.de>
List-Unsubscribe: <http://www.saout.de/mailman/options/dm-crypt>,
 <mailto:dm-crypt-request@saout.de?subject=unsubscribe>
List-Archive: <http://www.saout.de/pipermail/dm-crypt/>
List-Post: <mailto:dm-crypt@saout.de>
List-Help: <mailto:dm-crypt-request@saout.de?subject=help>
List-Subscribe: <http://www.saout.de/mailman/listinfo/dm-crypt>,
 <mailto:dm-crypt-request@saout.de?subject=subscribe>
To: mhogomchungu@gmail.com
Cc: dm-crypt <dm-crypt@saout.de>


On 19.3.2013 3:24, .. ink .. wrote:
> and what about truecrypt volume? The point is that when the
> underlying device is gone,the API becomes contradicting and
> unpredictable as it start to exhibit undocumented behaviors.

No, crypt_get_type() should return NULL in this case ("unknown").
This is documented value.

...
> There is another API i do not remember at the moment than return
> undocumented NULL in this situation.

For unknown type the query operations are not defined (resp. you get NULL)
because itnerenaly it is is nor (yet) recognised.

But yes, it should be probably unified and documented better (NULL
seems to missing in doc in some query commands).
(In fact, underlying device cannot disapper if in use - there is still
(in kernel) some reference used in maping table but userspace behaves
diferently seems.)

Milan