KeyError: 'storage.cdrom.cdr'

Can you please try this from the console, when you are at your computer at the same state as this failure happens?

$ /usr/lib/python2.4/site-packages/HUBackup/backend/DeviceInfo.py

and paste the output here?

Thanks

(11:45) [mario@Bilbo:~] 1 $ /usr/lib/python2.4/site-packages/HUBackup/backend/DeviceInfo.py
Traceback (most recent call last):
  File "/usr/lib/python2.4/site-packages/HUBackup/backend/DeviceInfo.py", line 150, in ?
    a = HUBDeviceDict(rwOnly=True,rmvOnly=True)
  File "/usr/lib/python2.4/site-packages/HUBackup/backend/DeviceInfo.py", line 106, in __init__
    StorageDeviceDict.__init__(self)
  File "/usr/lib/python2.4/site-packages/HUBackup/backend/DeviceInfo.py", line 60, in __init__
    ReadWrite = 1 and Type == "disk" or Type == "floppy" or \
KeyError: 'storage.cdrom.cdr'

Same Thing...

:)

hrm :-) Could you please send me a list of removable and cdrom devices you have on your system?

[4294673.873000] Probing IDE interface ide0...
[4294674.801000] hdb: IOMEGA ZIP 250 ATAPI, ATAPI FLOPPY drive
[4294674.853000] hdb: set_drive_speed_status: status=0x51 { DriveReady SeekComplete Error }
[4294674.853000] hdb: set_drive_speed_status: error=0x04 { AbortedCommand }
[4294674.853000] ide0 at 0x1f0-0x1f7,0x3f6 on irq 14
[4294674.860000] Probing IDE interface ide1...
[4294675.532000] hdc: HL-DT-ST GCE-8520B, ATAPI CD/DVD-ROM drive
[4294676.246000] hdd: HL-DT-STDVDRRW GWA-4164B, ATAPI CD/DVD-ROM drive
[4294676.298000] ide1 at 0x170-0x177,0x376 on irq 15
[4294676.320000] hdc: ATAPI 40X CD-ROM CD-R/RW drive, 2048kB Cache, UDMA(33)
[4294676.320000] Uniform CD-ROM driver Revision: 3.20
[4294676.324000] hdd: ATAPI 40X DVD-ROM DVD-R CD-R/RW drive, 2048kB Cache, UDMA(33)

[4294703.815000] Vendor: SanDisk Model: Cruzer Mini Rev: 0.1
[4294703.815000] Type: Direct-Access ANSI SCSI revision: 02
[4294703.816000] SCSI device sdb: 4001760 512-byte hdwr sectors (2049 MB)
[4294703.817000] sdb: Write Protect is off
[4294703.817000] sdb: Mode Sense: 03 00 00 00
[4294703.817000] sdb: assuming drive cache: write through
[4294703.819000] SCSI device sdb: 4001760 512-byte hdwr sectors (2049 MB)
[4294703.820000] sdb: Write Protect is off
[4294703.820000] sdb: Mode Sense: 03 00 00 00
[4294703.820000] sdb: assuming drive cache: write through
[4294703.820000] sdb: sdb1 sdb2

Resuming:
- IOMEGA ZIP 250 ATAPI (hdb)
- HL-DT-ST GCE-8520B, ATAPI CD/DVD-ROM drive (hdc)
- HL-DT-STDVDRRW GWA-4164B, ATAPI CD/DVD-ROM drive (hdd)
- SanDisk Cruzer Mini 2.0GB (sdb)

Bug confirmed... The program throws an error when trying to access "storage.cdrom.*" info from a ZIP Drive...

Mario, currently I have only two options to fix this in mind:

1) Check for CDROMness, if not, assume everything is like Type == 'disk' , meaning, assuming everything else but CDROMs cannot be un-writeable
2) check for each and every drive_type be it zip, disk, cdrom etc.. I reckon there are not so much types and they get seldomly updated as they go by storage technology rather by branding.

Any thoughts?

Sivan,

I think you (we?) could do a strategy somewhat including both 1) and
2)... We could create a more generalistic solution to the problem so
that the application wouldn't crash, as it has happened on my test
case... Then there could be more specific handling for sotrage types we
get in touch with... i.e. now that we have an zip-drive on my computer
to test, it's a great opportunity to code for it.. Whenever someone asks
for a more "specific" handling, we do it..

Any specific-only solution will end in a bug-prone software, and you'll
get lots of bug reports for it everytime it is launched on a computer
with a different kind of storage... But having storage type specific
features is also desirable...

For the generalistc approach i would (personaly) use an exception
treatment... printing something to the console or having a GUI frontend
asking for the user to report that error.. or maybe even asking if the
user allows the software to send debbug info automaticaly trough the
user's internet connection (never do it without asking)..

What do you think about that?

Mario

Sivan Greenberg escreveu:
> Mario, currently I have only two options to fix this in mind:
>
> 1) Check for CDROMness, if not, assume everything is like Type == 'disk' , meaning, assuming everything else but CDROMs cannot be un-writeable
> 2) check for each and every drive_type be it zip, disk, cdrom etc.. I reckon there are not so much types and they get seldomly updated as they go by storage technology rather by branding.
>
> Any thoughts?
>
>