On 01/27/2011 09:56 AM, Denys Vlasenko wrote:
On Wed, 2011-01-26 at 21:15 +0100, Jiri Moskovcak wrote:
> On 01/26/2011 08:24 PM, Denys Vlasenko wrote:
>> Hi,
>>
>> After a quick look at abrt-cli source, I think this can be approached
>> like this:
>>
>> We add -D DIR option which specifies which directory to list.
>> It can be used more than once. If it is not specified,
>> abrt-cli defaults to -D /var/spool/abrt -D $HOME/abrt/spool.
>>
>> With "abrt-cli --list", dumps from all these directories
>> are shown.
>>
>
> - what are you going to show here?
The same thing we already show:
# abrt-cli --list --full
Getting crash infos...
0.
Crash dump : /var/spool/abrt/ccpp-1294848465-26639
UID : 0
Package : coreutils-8.4-10.fc13
Executable : /bin/sleep
Crash Time : Wed 12 Jan 2011 05:07:45 PM CET
Crash Count: 4
Hostname :
dhcp-25-227.brq.redhat.com
1.
Crash dump : /var/spool/abrt/ccpp-1294848466-26657
UID : 0
Package : hdparm-9.27-1.fc13
Executable : /sbin/hdparm
Crash Time : Wed 12 Jan 2011 05:07:46 PM CET
Crash Count: 1
Hostname :
dhcp-25-227.brq.redhat.com
> if the second then
> you'll hit the locking problem again.. unless you ask the daemon to give
> you the data...
What problem? The dump which can't be locked for writing
may be still possible to read. If it can't be read too,
then we don't show it.
- dd_open() tries to lock the dir anyway, it doesn't know if you want to
write or read...
>> When "abrt-cli --report DUMP_DIR" is run and
abrt-cli detects
>> that it can't lock DUMP_DIR for writing, it informs the user:
>>
>> DUMP_DIR is not writable.
>> Do you want to copy it to $HOME/abrt/spool? (y/n)
>>
>> (The directory to copy to can be specified by another option,
>> -W DIR; or we can have a convention that the DIR from the
>> first -D DIR option is used)
>>
>
> - this sounds ok
>
>> When "abrt-cli --delete DUMP_DIR" is run and abrt-cli detects
>> that it can't lock DUMP_DIR for writing, it tries to delete
>> the directory through dbus call to abrtd.
>>
>
> - I'm ok with this, but at one point we will have to make the surgery
> and cut the dbus from daemon (or we can leave it if we can live with the
> dbus dependency...)