Stored Properties file gets emptied

[Sabine Dinis Blochberger]

It seems there is a bug with our XMPP client (Java 1.6, smack) - I store
the users settings in a Properties file. My boss tells me on some
customers PCs the settings file sometimes ends up losing the contents.

The application is used by two people in our company in production, I
debug before release. None of us is able to reproduce the effect.

I'll not post a SCCE yet, maybe something will jump out at someone more
experienced. My hunch is that it sometimes gets replaced with the
default properties, which according to the Javadocs does not get written
out (empty file, I assume rather then no file at all).

The application is a JWS app and uses the SingleInstanceService
<http://java.sun.com/javase/6/docs/technotes/guides/javaws/developersguide/examples.html#SingleInstanceService>>.
(it only pops up a dialog then exits the second instance).

I encapsulate the settings thusly:

public class Settings {

public final static int DEF_SEC_PORT = 5223;
public final static int DEF_PORT = 5222;
// etc
private boolean saveToFile = false;

private Properties defaultProperties;
private Properties userSettings;

private String settingsDirName;
private File settingsFile;

/**
* Creates a new instance of Settings.
* @param settingsDir directory where to find/keep the
* settings file.
* when null, does not write a file
*/
public Settings(String settingsDir) {

if (settingsDir != null && !settingsDir.isEmpty()) {
settingsDirName = settingsDir + "/" ;
settingsFile = new File(settingsDirName +
SETTINGS_FILE_NAME);
saveToFile = true;
} else saveToFile = false;

// initialize default values
defaultProperties = new Properties();
defaultProperties.setProperty("autoAway", String.valueOf(true));
defaultProperties.setProperty("autoAwayAfter",
String.valueOf(5));
defaultProperties.setProperty("identifyAsResource",
DEFAULT_RESOURCE);
//etc

returnToDefaults();

if (saveToFile) {
if (!readSettingsFile()) {
writeSettingsFile();
}
}
}

public final void returnToDefaults() {
userSettings = new Properties(defaultProperties);
}

public boolean writeSettingsFile() {
if (!saveToFile) return false;

FileOutputStream out = null;
try {
// save settings
out = new FileOutputStream(settingsFile);
userSettings.store(out, "---Auto generated---");
out.close();
} catch (FileNotFoundException ex) {
ex.printStackTrace();
return false;
} catch (IOException ex) {
ex.printStackTrace();
return false;
}
finally{
if (out != null)
try {
out.close();
} catch (IOException ex) {
//ex.printStackTrace();
}
}
return true;
}

public boolean readSettingsFile() {
FileInputStream in = null;
try {
// read settings
in = new FileInputStream(settingsFile);
userSettings.load(in);
in.close();
} catch (FileNotFoundException ex) {
ex.printStackTrace();
return false;
} catch (IOException ex) {
ex.printStackTrace();
return false;
}
finally {
if (in != null)
try {
in.close();
} catch (IOException ex) {
//ex.printStackTrace();
}
}
return true;
}

// main window position
/** Returns last main window position */
public final Point windowPosXY() {
//snip
}
/** Sets last main window position.
* @param pos position */
public final void windowPosXY(Point pos) {
//snip
}
// General settings
/** Returns auto away on or off */
public final boolean autoAway() {
return Boolean.valueOf(userSettings.getProperty("autoAway",
defaultProperties.getProperty("autoAway")));
}
/** Sets auto away setting.
* @param autoAway turn on or off */
public final void autoAway(boolean autoAway) {
userSettings.setProperty("autoAway", String.valueOf(autoAway));
}
// etc

The class is instanciated in the application at start up with

private static final String APP_HOME =
System.getProperties().getProperty("appdir");
private static final String USER_HOME =
System.getProperties().getProperty("user.home");
private static final String USER_APP_HOME = USER_HOME + "/op3mi";

if (APP_HOME == null) {
OPTIONS_DIRECTORY = new File(USER_APP_HOME, "/" +
OPTIONS_DIR_NAME).getAbsoluteFile();
} else {
OPTIONS_DIRECTORY = new File(APP_HOME, "/" +
OPTIONS_DIR_NAME).getAbsoluteFile();
}
appSettings = new Settings(OPTIONS_DIRECTORY.getAbsolutePath());

Thanks to any ideas in advance.
--
Op3racional - www.op3racional.eu
---------------------
If you're reading this, you're on Usenet
<http://oakroadsystems.com/genl/unice.htm>

[John B. Matthews]

In article <tO2dnWN5weXPoWTX...@novis.pt>,

Sabine Dinis Blochberger <no....@here.invalid> wrote:

> It seems there is a bug with our XMPP client (Java 1.6, smack) - I
> store the users settings in a Properties file. My boss tells me on
> some customers PCs the settings file sometimes ends up losing the
> contents.
>
> The application is used by two people in our company in production, I
> debug before release. None of us is able to reproduce the effect.
>
> I'll not post a SCCE yet, maybe something will jump out at someone
> more experienced. My hunch is that it sometimes gets replaced with
> the default properties, which according to the Javadocs does not get
> written out (empty file, I assume rather then no file at all).

[...]

> settingsDirName = settingsDir + "/" ;

[...]

> Thanks to any ideas in advance.

Should that be the system property file.separator or the constant
java.io.File.separator?

I'm not sure it's apropos, but I've had positive cross-platform
experiences using the Preferences class of java.util.prefs. Here's a
simple example:

<http://robotchase.svn.sourceforge.net/viewvc/robotchase/trunk/
src/org/gcs/robot/RCPrefs.java?revision=39&view=markup>

--
John B. Matthews
trashgod at gmail dot com
<http://sites.google.com/site/drjohnbmatthews>

[Noel]

Sabine Dinis Blochberger wrote:
> [...] My hunch is that it sometimes gets replaced with the

> default properties, which according to the Javadocs does not get written
> out (empty file, I assume rather then no file at all).
>

Calling Properties.store on a Properties object with only default
properties will produce (at least using Windows x64 Sun JRE 1.6 JVM) a
non-empty file consisting of at least a comment line with the
modification date-time. You would also see the comment "#---Auto
generated---" given your code.

Is the application occasionally producing files that are completely empty?

Also, your constructor code mainly gives us an idea what's occurring at
app start-up time, but consider the possibility that the property files
are getting "emptied" elsewhere in its life cycle.

> public Settings(String settingsDir) {
> [...]

> returnToDefaults();
>
> if (saveToFile) {
> if (!readSettingsFile()) {
> writeSettingsFile();
> }
> }
> }
>

Any code path thru the constructor that manages to call
writeSettingsFile() will always produce a properties-empty file. I
suggest logging exceptions to see if the problem can be correlated to
intermittent failure by readSettingsFile() to open an existing file for
reading, or to load from it.

[Sabine Dinis Blochberger]

Noel wrote:

> Sabine Dinis Blochberger wrote:
> > [...] My hunch is that it sometimes gets replaced with the
> > default properties, which according to the Javadocs does not get written
> > out (empty file, I assume rather then no file at all).
> >
>
> Calling Properties.store on a Properties object with only default
> properties will produce (at least using Windows x64 Sun JRE 1.6 JVM) a
> non-empty file consisting of at least a comment line with the
> modification date-time. You would also see the comment "#---Auto
> generated---" given your code.
>
> Is the application occasionally producing files that are completely empty?

Unfortunately, the bug report is just verbal from the customer to my
boss then to me. The application also has no logging facility, only the
java console would show exceptions and most people have it turned off.
That and it's a bit much to ask customers to debug our stuff.

>
> Also, your constructor code mainly gives us an idea what's occurring at
> app start-up time, but consider the possibility that the property files
> are getting "emptied" elsewhere in its life cycle.
>
> > public Settings(String settingsDir) {
> > [...]
> > returnToDefaults();
> >
> > if (saveToFile) {
> > if (!readSettingsFile()) {
> > writeSettingsFile();
> > }
> > }
> > }
> >
>
> Any code path thru the constructor that manages to call
> writeSettingsFile() will always produce a properties-empty file. I
> suggest logging exceptions to see if the problem can be correlated to
> intermittent failure by readSettingsFile() to open an existing file for
> reading, or to load from it.

Yes, thanks for your thoughts. I also think that those lines are the
culprit - reading fails for some reason and it sets the defaults and
creates the empty file.

I'll see if it maybe is realted to starting a second instance of the
application, the file may be locked by the first (although then it
couldn't replace with an empty file either)...

I'll see if I can get more info out of the exception.

[Sabine Dinis Blochberger]

John B. Matthews wrote:

> In article <tO2dnWN5weXPoWTX...@novis.pt>,
> Sabine Dinis Blochberger <no....@here.invalid> wrote:
>
> > It seems there is a bug with our XMPP client (Java 1.6, smack) - I
> > store the users settings in a Properties file. My boss tells me on
> > some customers PCs the settings file sometimes ends up losing the
> > contents.
> >
> > The application is used by two people in our company in production, I
> > debug before release. None of us is able to reproduce the effect.
> >
> > I'll not post a SCCE yet, maybe something will jump out at someone
> > more experienced. My hunch is that it sometimes gets replaced with
> > the default properties, which according to the Javadocs does not get
> > written out (empty file, I assume rather then no file at all).
> [...]
> > settingsDirName = settingsDir + "/" ;
> [...]
> > Thanks to any ideas in advance.
>
> Should that be the system property file.separator or the constant
> java.io.File.separator?
>

I gather it should be one of those <g>. I'll change it after looking
them up.

> I'm not sure it's apropos, but I've had positive cross-platform
> experiences using the Preferences class of java.util.prefs. Here's a
> simple example:
>
> <http://robotchase.svn.sourceforge.net/viewvc/robotchase/trunk/
> src/org/gcs/robot/RCPrefs.java?revision=39&view=markup>
>

Thanks for the tip, I'll have to take a closer look. In your code, there
is no method for storing in a file though.

[Sabine Dinis Blochberger]

Sabine Dinis Blochberger wrote:

> John B. Matthews wrote:
>
> > In article <tO2dnWN5weXPoWTX...@novis.pt>,
> > Sabine Dinis Blochberger <no....@here.invalid> wrote:
> >
> > > It seems there is a bug with our XMPP client (Java 1.6, smack) - I
> > > store the users settings in a Properties file. My boss tells me on
> > > some customers PCs the settings file sometimes ends up losing the
> > > contents.
> > >

> > I'm not sure it's apropos, but I've had positive cross-platform
> > experiences using the Preferences class of java.util.prefs. Here's a
> > simple example:
> >
> > <http://robotchase.svn.sourceforge.net/viewvc/robotchase/trunk/
> > src/org/gcs/robot/RCPrefs.java?revision=39&view=markup>
> >
> Thanks for the tip, I'll have to take a closer look. In your code, there
> is no method for storing in a file though.

I looked at the Javadoc and it seems the Preferences aren't really
available to be edited outside the application, a functionality I need
for debugging. I use a different XMPP server to debug, and with
Properties I can edit the file, which I can find more easily.

[Sabine Dinis Blochberger]

Sabine Dinis Blochberger wrote:

> It seems there is a bug with our XMPP client (Java 1.6, smack) - I store
> the users settings in a Properties file. My boss tells me on some
> customers PCs the settings file sometimes ends up losing the contents.
>
> The application is used by two people in our company in production, I
> debug before release. None of us is able to reproduce the effect.
>

Turns out my boss has had the effect. I told him to keep the Java
console on to catch the exception.

[John B. Matthews]

In article <PeqdnawgvtxJEmfX...@novis.pt>,

Sabine Dinis Blochberger <no....@here.invalid> wrote:

> Sabine Dinis Blochberger wrote:
>
> > John B. Matthews wrote:
> >
> > > In article <tO2dnWN5weXPoWTX...@novis.pt>,
> > > Sabine Dinis Blochberger <no....@here.invalid> wrote:
> > >
> > > > It seems there is a bug with our XMPP client (Java 1.6, smack)
> > > > - I store the users settings in a Properties file. My boss
> > > > tells me on some customers PCs the settings file sometimes ends
> > > > up losing the contents.

> > > > [...]
> > > settingsDirName = settingsDir + "/" ;
> > > [...]

> > Should that be the system property file.separator or the constant
> > java.io.File.separator?
> >
> I gather it should be one of those <g>. I'll change it after looking
> them up.

I should have said xor :-) File.separator is a little more convenient:

<http://java.sun.com/javase/6/docs/api/java/io/File.html>

I thought Windows might balk at "/" in a path name, but now I'm not so
sure.

> > > I'm not sure it's apropos, but I've had positive cross-platform
> > > experiences using the Preferences class of java.util.prefs.
> > > Here's a simple example:
> > >
> > > <http://robotchase.svn.sourceforge.net/viewvc/robotchase/trunk/
> > > src/org/gcs/robot/RCPrefs.java?revision=39&view=markup>
> > >
> > Thanks for the tip, I'll have to take a closer look. In your code,
> > there is no method for storing in a file though.
>
> I looked at the Javadoc and it seems the Preferences aren't really
> available to be edited outside the application, a functionality I
> need for debugging. I use a different XMPP server to debug, and with
> Properties I can edit the file, which I can find more easily.

Ah, I see. The destination varies widely among platforms: on Mac,
~/Library/Preferences; on linux, ~/.java; on Windows, the registry!

<http://mindprod.com/jgloss/preferences.html>

[Patricia Shanahan]

Sabine Dinis Blochberger wrote:
> Noel wrote:
>
>> Sabine Dinis Blochberger wrote:
>>> [...] My hunch is that it sometimes gets replaced with the
>>> default properties, which according to the Javadocs does not get written
>>> out (empty file, I assume rather then no file at all).
>>>
>> Calling Properties.store on a Properties object with only default
>> properties will produce (at least using Windows x64 Sun JRE 1.6 JVM) a
>> non-empty file consisting of at least a comment line with the
>> modification date-time. You would also see the comment "#---Auto
>> generated---" given your code.
>>
>> Is the application occasionally producing files that are completely empty?
>
> Unfortunately, the bug report is just verbal from the customer to my
> boss then to me. The application also has no logging facility, only the
> java console would show exceptions and most people have it turned off.
> That and it's a bit much to ask customers to debug our stuff.

...

True, you cannot ask a customer to debug your stuff, and any approach to
one must be coordinated with whoever is primarily responsible for
relations with that customer. On the other hand, from a customer point
of view, the following can all be positive messages:

1. We are taking the problem seriously.

2. Here is the actual, living, breathing, thinking programmer who has
been assigned to fix the problem.

3. You may have the power to help expedite a fix by supplying additional
data.

Framed like that, you may be able to get to speak with someone who has
seen the problem happen, and can answer questions like "Is the file
totally empty, or does it contain comments?". You might be able to
communicate "We want to fix the problem before you see it again, but
just in case please enable your Java console and, if it happens, send a
copy with the bug report, along with a copy of the file."

Patricia

[Steven Simpson]

Sabine Dinis Blochberger wrote:
> It seems there is a bug with our XMPP client (Java 1.6, smack) - I store
> the users settings in a Properties file. My boss tells me on some
> customers PCs the settings file sometimes ends up losing the contents.

[...]

> The class is instanciated in the application at start up with
>
> private static final String APP_HOME =
> System.getProperties().getProperty("appdir");
> private static final String USER_HOME =
> System.getProperties().getProperty("user.home");
> private static final String USER_APP_HOME = USER_HOME + "/op3mi";
>
> if (APP_HOME == null) {
> OPTIONS_DIRECTORY = new File(USER_APP_HOME, "/" +
> OPTIONS_DIR_NAME).getAbsoluteFile();
> } else {
> OPTIONS_DIRECTORY = new File(APP_HOME, "/" +
> OPTIONS_DIR_NAME).getAbsoluteFile();
> }
>

These seem a little odd. If you're using the two-argument File
constructors, while bother inserting a separator? (Actually, I prefer
to handle paths this way than to access file.separator or similar.)

The docs say that an absolute child argument (the second one) will be
converted in a system-dependent way, so while the leading '/' seems
benign on my system (testing with the program below), it might be
different on yours or your customers'.

import java.io.*;

public class Subfile {
public static void main(String[] args) {
System.out.println(new File(args[0], args[1]));
}
}

--
ss at comp dot lancs dot ac dot uk

[Kenneth P. Turvey]

On Wed, 11 Nov 2009 10:20:03 +0000, Sabine Dinis Blochberger wrote:

[Snip]

> I looked at the Javadoc and it seems the Preferences aren't really
> available to be edited outside the application, a functionality I need
> for debugging. I use a different XMPP server to debug, and with
> Properties I can edit the file, which I can find more easily.

If it is only a debugging issue, you shouldn't have any problem locating
the preferences on any given machine. It may be in different places, but
it isn't hidden.

--
Kenneth P. Turvey <evot...@gmail.com>
http://www.electricsenator.net

[Sabine Dinis Blochberger]

Sabine Dinis Blochberger wrote:

> It seems there is a bug with our XMPP client (Java 1.6, smack) - I store
> the users settings in a Properties file. My boss tells me on some
> customers PCs the settings file sometimes ends up losing the contents.
>

There was a call to writeSettings in the applications shutdownHook that
I since changed. It was for saving the window position, so not critical.

Could it be that a try to write to the file in that circumstance could
lead to an empty or deleted file?

Rest of post quoted for completeness (no new text from me after).