Deleted files should go into Trash/Recycle Bin
Reported by delisa | October 19th, 2010 @ 11:24 PM
When I deleted a file (and it isn't versioned) its gone forever, even if I just click on it accidentally in the project tree.
Comments and changes to this ticket
-
tim.felgentreff (at student.hpi.uni-potsdam) October 20th, 2010 @ 01:02 PM
That could be done:
For OS X there's the osx-trash gem, for Linux there's the freedesktop specification on where to move files. We could also query the WM for the trash location. It's been a while since I've done any WM programming, but I could look how to do that. For Windows, there are very short Perl or VBscript snippets we could use, executing VBscript from Ruby isn't too bad, I guess. -
delisa October 22nd, 2010 @ 09:49 PM
Currently I'm getting this:
Errno::EACCES: Permission denied - /Code/redcar/plugins/runnables/New File or /home/delisa/New File (repl):1 file:/home/delisa/.redcar/assets/jruby-complete-1.5.2.jar!/META-INF/jruby.home/lib/ruby/1.8/fileutils.rb:505:in `mv' file:/home/delisa/.redcar/assets/jruby-complete-1.5.2.jar!/META-INF/jruby.home/lib/ruby/1.8/fileutils.rb:1396:in `fu_each_src_dest' file:/home/delisa/.redcar/assets/jruby-complete-1.5.2.jar!/META-INF/jruby.home/lib/ruby/1.8/fileutils.rb:1410:in `fu_each_src_dest0' file:/home/delisa/.redcar/assets/jruby-complete-1.5.2.jar!/META-INF/jruby.home/lib/ruby/1.8/fileutils.rb:1394:in `fu_each_src_dest' file:/home/delisa/.redcar/assets/jruby-complete-1.5.2.jar!/META-INF/jruby.home/lib/ruby/1.8/fileutils.rb:494:in `mv'
And that's just from calling a mv directly, outside of the trash function.
FileUtils.mv( "/Code/redcar/plugins/runnables/New File", "/home/delisa" )
I think my problem with the current solution is that I can't delete/move a file across partitions.
After playing with it for a bit i remembered having the same problem with some Java apps which needed to copy files into my source code partition. I'm not sure its fixable.From the Java 6 API (this may or may not be related?):
File.renameTo "Many aspects of the behavior of this method are inherently platform-dependent: The rename operation might not be able to move a file from one filesystem to another, it might not be atomic, and it might not succeed if a file with the destination abstract pathname already exists. The return value should always be checked to make sure that the rename operation was successful."
-
tim.felgentreff (at student.hpi.uni-potsdam) October 23rd, 2010 @ 08:02 PM
Should be fixed in latest master.
Please Sign in or create a free account to add a new ticket.
With your very own profile, you can contribute to projects, track your activity, watch tickets, receive and update tickets through your email and much more.