Is it intentional that sys.props is kept locked while the fan runtime is live? I guess there could be a reason for that, but I don't see it.

I noticed it while trying to update to tip while Flux is loaded; couldn't merge the sys.props file.

A quick search just shows it being opened and read in sys/java/fan/sys/Sys.java:

// sys.properties
LocalFile f = new LocalFile(new File(HomeDir, "lib" + File.separator + "sys.props"));
if (f.exists())
{
  try
  {
    Map props = f.readProps();
    env.setAll(props);
  ...

Shouldn't the file's instream be getting closed, like in a finally block? The other readXXX methods in File.java seem to be doing a close on their streams, but not readProps.

It doesn't actually matter to me in this case, but it made me wonder and go looking.

sounds like a bug, I'll take a look once I get settled into my "vacation office"

We should always be closing that file:

• Sys calls sys::File.readProps
• Which routes to sys::InStream.readProps
• Which uses a finally block to close the stream

So I am not sure how you are seeing that file locked - it should be closed.

Yeah, it looks like it should be. It's not just Flux; starting a fansh shell locks it too. (Start a fansh; attempt to rename sys.props in windows explorer; fails; exit fansh; try again; rename succeeds)

I sprinkled in some println's in LocalFile.java and SysInStream.java, and close is being called, and acts as though it's succeeding.

JavaDocs for FileInputStream say that close releases all system resources.

So, I don't get it. Like I said I don't know if it matters; but it's weirding me out.