On 06/15/2017 09:44 AM, Michal Privoznik wrote:
> On 06/15/2017 02:03 PM, John Ferlan wrote:
>>
>>
>> On 06/15/2017 04:53 AM, Michal Privoznik wrote:
>>> On 06/14/2017 09:50 PM, John Ferlan wrote:
On 06/12/2017 11:57 AM, Michal Privoznik wrote:
>
On 06/15/2017 02:03 PM, John Ferlan wrote:
>
>
> On 06/15/2017 04:53 AM, Michal Privoznik wrote:
>> On 06/14/2017 09:50 PM, John Ferlan wrote:
>>>
>>>
>>> On 06/12/2017 11:57 AM, Michal Privoznik wrote:
https://bugzilla.redhat.com/show_bug.cgi?id=1431112
After 290a00e41d we know
On 06/15/2017 04:53 AM, Michal Privoznik wrote:
> On 06/14/2017 09:50 PM, John Ferlan wrote:
>>
>>
>> On 06/12/2017 11:57 AM, Michal Privoznik wrote:
>>> https://bugzilla.redhat.com/show_bug.cgi?id=1431112
>>>
>>> After 290a00e41d we know how to deal with file mount points.
>>> However, when
On 06/14/2017 09:50 PM, John Ferlan wrote:
>
>
> On 06/12/2017 11:57 AM, Michal Privoznik wrote:
>> https://bugzilla.redhat.com/show_bug.cgi?id=1431112
>>
>> After 290a00e41d we know how to deal with file mount points.
>> However, when cleaning up the temporary location for preserved
>> mount
On 06/12/2017 11:57 AM, Michal Privoznik wrote:
> https://bugzilla.redhat.com/show_bug.cgi?id=1431112
>
> After 290a00e41d we know how to deal with file mount points.
> However, when cleaning up the temporary location for preserved
> mount points we are still calling rmdir(). This won't fly for
https://bugzilla.redhat.com/show_bug.cgi?id=1431112
After 290a00e41d we know how to deal with file mount points.
However, when cleaning up the temporary location for preserved
mount points we are still calling rmdir(). This won't fly for
files. We need to call unlink(). Now, since we don't really