Learn how easy it is to sync an existing GitHub or Google Code repo to a SourceForge project! See Demo


#8 Entries without passwords are deleted when saving.


Any entries without passwords are deleted from the database without warning when saving or converting from older formats to psafe3.

This is very bad behavior! I have entries in my password database which may not yet have passwords. For example, I store credit card information in my password database with the PIN number as the password. If I have a credit card which does not yet have a PIN, there is no password in the database.

I first noticed this when converting a database from an older version of Password Gorilla. There were no errors or warnings, but I noticed that an entry was missing. Then I converted the database to psafe3 format with a newer version of Password Gorilla and loaded it into JPasswords and the entries without passwords show up but are deleted as soon as I save the database, again without error or warning.

Even if I wanted to go to the trouble of adding fake passwords for those entries without them, I would have to go through every entry one at a time to check to see if there was a password.

System Information:

Application Properties
Init Modus = NORMAL OS Modus = WINDOWS Locale = , Option File = /usr2/paulk/jpws.ini Command Line = Program Dir = /usr/local/lib Current Dir = /usr2/paulk/Personal Backup Dir = /net/youngs/rzpool/local/local_src/Security Exchange Dir = /usr2/paulk
Runtime System Properties
file.encoding = ISO646-US file.encoding.pkg = sun.io file.separator = / java.awt.graphicsenv = sun.awt.X11GraphicsEnvironment java.awt.printerjob = sun.print.PSPrinterJob java.class.path = /usr/local/lib/jpws-deluxe-0-5-0.jar java.class.version = 50.0 java.endorsed.dirs = /tools/jdk1.6.0/jre/lib/endorsed java.ext.dirs = /tools/jdk1.6.0/jre/lib/ext:/usr/jdk/packages/lib/ext java.home = /tools/jdk1.6.0/jre java.io.tmpdir = /var/tmp/ java.library.path = /tools/jdk1.6.0/jre/lib/sparc/server:/tools/jdk1.6.0/jre/lib/sparc:/tools/jdk1.6.0/jre/../lib/sparc:/usr/dt/lib:/usr/local/lib:/usr2/paulk/Arch/sparc-sunos5/lib:/usr2/paulk/lib/sparc-sunos5:/usr2/paulk/lib/sparc-sunos5.8:/usr/openwin/lib:/usr/lib:/usr/jdk/packages/lib/sparc:/usr/lib java.runtime.name = Java(TM) SE Runtime Environment java.runtime.version = 1.6.0_03-b05 java.specification.name = Java Platform API Specification java.specification.vendor = Sun Microsystems Inc. java.specification.version = 1.6 java.vendor = Sun Microsystems Inc. java.vendor.url = http://java.sun.com/ java.vendor.url.bug = http://java.sun.com/cgi-bin/bugreport.cgi java.version = 1.6.0_03 java.vm.info = mixed mode java.vm.name = Java HotSpot(TM) Server VM java.vm.specification.name = Java Virtual Machine Specification java.vm.specification.vendor = Sun Microsystems Inc. java.vm.specification.version = 1.0 java.vm.vendor = Sun Microsystems Inc. java.vm.version = 1.6.0_03-b05 line.separator = os.arch = sparc os.name = SunOS os.version = 5.8 path.separator = : sun.arch.data.model = 32 sun.boot.class.path = /tools/jdk1.6.0/jre/lib/resources.jar:/tools/jdk1.6.0/jre/lib/rt.jar:/tools/jdk1.6.0/jre/lib/sunrsasign.jar:/tools/jdk1.6.0/jre/lib/jsse.jar:/tools/jdk1.6.0/jre/lib/jce.jar:/tools/jdk1.6.0/jre/lib/charsets.jar:/tools/jdk1.6.0/jre/classes sun.boot.library.path = /tools/jdk1.6.0/jre/lib/sparc sun.cpu.endian = big sun.cpu.isalist = sun.io.unicode.encoding = UnicodeBig sun.java.launcher = SUN_STANDARD sun.jnu.encoding = ISO646-US sun.management.compiler = HotSpot Server Compiler sun.os.patch.level = unknown user.dir = /usr2/paulk/SR/678056/logs1024 user.home = /usr2/paulk user.language = en user.name = paulkeus user.timezone = US/Central #


  • I just noticed that previous bug report 1864140 looks suspiciously similar to this one: conversion from a .dat file to a psafe3 file loses records without a password.

    • labels: 765096 --> JPWS - Compatibility
    • assigned_to: nobody --> kse
    • milestone: --> 519195
    • priority: 5 --> 6
  • I confirm this is regular behaviour and is due to a semantic rule in JPasswords on minimum data in a record, namely title and password.

    I agree the present situation is not satisfying and at least a warning, and better still a list of affected records, should be available in the event where an "inconsistent" database is loaded.

    I will further look into it whether a relaxation of the semantic rule is both possible and desirable. I'ld still like to stress that this is a password database and not a generic notes database.

    - Wolfgang

  • I have implemented the following rule set for program version 0-6-0:

    a) invalid records cannot be entered into the database via JPasswords (editor)
    b) invalid records may not be entered through the import functionality
    c) invalid records have a persistent life in the database, including save operations, once they are entered via other applications or through the merge functionality
    d) invalid records are not represented in database exports
    e) there is a warning message upon loading of a database if it contains invalid records
    f) there is a new filtering modus to show only invalid records



Cancel   Add attachments