Redcar Holding On To Files

[Stephen Duncan Jr]

I've only noticed this happening since updating redcar post 0.11 (so
0.12 & 0.13). This is on windows. I also use git on windows, so I
frequently notice when attempting to use git to modify files (stash,
branch change, etc.) that it can't because the file is locked. Using
Process Explorer I'm able to identify that the javaw process running
redcar is the culprit. Is this possibly something that was
accidentally introduced in recent versions?

Stephen Duncan Jr
www.stephenduncanjr.com

[Stephen Duncan Jr]

This is starting to be a deal-breaker for my use of redcar; it's
keeping file handles open unless I close the redcar window
frequently. Is there at least somewhere in the code I could be
pointed to in order to investigate this?

On Jan 31, 2:59 pm, Stephen Duncan Jr <stephen.dun...@gmail.com>
wrote:

[Andrew Jones]

I use Redcar (and git) on Windows 7 and haven't seen this problem.
Maybe your version of Java, JRuby, etc? I think I am using the latest
versions of each, as my PC is only a few weeks old.

Andrew

> --
> You received this message because you are subscribed to the Google Groups "Redcar" group.
> To post to this group, send email to redcar...@googlegroups.com.
> To unsubscribe from this group, send email to redcar-edito...@googlegroups.com.
> For more options, visit this group at http://groups.google.com/group/redcar-editor?hl=en.
>

[Roger Pack]

> This is starting to be a deal-breaker for my use of redcar; it's
> keeping file handles open unless I close the redcar window
> frequently.  Is there at least somewhere in the code I could be
> pointed to in order to investigate this?

You can "kind of" debug it by carefully testing, after each step of
redcar, when it gets locked. Is it when you save it, so the formatter
runs, for example?

[Stephen Duncan Jr]

My Java version is 1.6.0_29 and my jruby version is 1.6.5. I'm also on
Windows 7.

Stephen Duncan Jr
www.stephenduncanjr.com

[Stephen Duncan Jr]

It is when it saves a file. It's not consistent on when it gives the
file back up. Once it only held a file briefly (10 seconds or so) and
gave it back without doing anything, but a subsequent change & save
caused the file to be held indefinitely until I closed the tab.
Sometimes it doesn't happen at all. It's happened to all file types,
both those that have highlighting, as well as a plain text file. I
was only able to see this behavior when having a directory (project)
open, but not when just opening a single file. A potential hypothesis
might be it has something to do with the lucene indexing that powers
the "Word Search" feature, or at least some other project-only
feature.

Stephen Duncan Jr
www.stephenduncanjr.com

[Roger Pack]

> It is when it saves a file.   It's not consistent on when it gives the
> file back up.  Once it only held a file briefly (10 seconds or so) and
> gave it back without doing anything, but a subsequent change & save
> caused the file to be held indefinitely until I closed the tab.
> Sometimes it doesn't happen at all.  It's happened to all file types,
> both those that have highlighting, as well as a plain text file.  I
> was only able to see this behavior when having a directory (project)
> open, but not when just opening a single file.  A potential hypothesis
> might be it has something to do with the lucene indexing that powers
> the "Word Search" feature, or at least some other project-only
> feature.

does the "syntax errror highlighting" also change on save? (I thought
we had fixed that bug, but it used to hang onto files...)

[Stephen Duncan Jr]

I'm not quite sure what you're asking. My tests involved adding
spaces or newlines & then saving, so there weren't any changes that
caused syntax errors.

Stephen Duncan Jr
www.stephenduncanjr.com

On Fri, Feb 10, 2012 at 1:01 PM, Roger Pack <roger...@gmail.com> wrote:
> does the "syntax errror highlighting" also change on save? (I thought
> we had fixed that bug, but it used to hang onto files...)
>

[Roger Pack]

> I'm not quite sure what you're asking.  My tests involved adding
> spaces or newlines & then saving, so there weren't any changes that
> caused syntax errors.

When you save it fires off a "file saved" message which various
plugins respond to (and one of them might be the culprit).
-r

[Daniel Lucraft]

Hi Stephen

Thanks for reporting this, this is quite troubling. 

In attempting to reproduce it, I've got to the point where I get this error message from git when doing "git stash":

  Unlink of file 'README.md' failed. Should I try again? (y/n) n

  error: unable to unlink old 'README.md' (Permission denied)

  fatal: Could not reset index file to revision 'HEAD'.

Is this the error you have been seeing? I've not been able to reproduce this in actual usage, only by using the Ruby REPL to open a File and not close it. I suspect that garbage collection will lead to the file being closed quickly in most but not all cases.

So I looked through all occurrences of the "File" class in Redcar where a file is opened or read from, and in almost all cases it is a simple File#read or the File#open has an accompanying block, so the file is automatically closed.

The cases where this isn't true:

 * in scm_svn, Java File objects are opened and passed to a Java API I'm not familiar with. I hope and assume this API is doing the right thing around closing them, and anyway you say you are using git not svn

 * in lucene_index.rb line 60, we do not appear to be closing a file handle and this is certainly a bug

If you have a moment, could you edit lucene_index.rb to close the file handle that is opened on line 60, and see if this fixes your problem?

thanks

Dan

[Stephen Duncan Jr]

Dan, thank you so much for looking into this. Yes, that was the
primary error message I was getting (in previous versions of git I
would just get permission denied errors). I made the change you
suggested, and it does appear to fix the problem (at least, it hasn't
occurred yet with several attempts to reproduce). I see you committed
the same fix already; I really appreciate the speedy response.
Hopefully now that I did the work to figure out where that file was
I'll feel a bit more comfortable investigating future issues myself.

Thanks,
Stephen

Stephen Duncan Jr
www.stephenduncanjr.com