Ticket #234 (reopened defect)

Opened 14 months ago

Last modified 6 months ago

Recycle Bin not working on Windows 64-bit

Reported by: GiantWaffle Owned by: maxence@…
Priority: high Milestone: 0.8.5
Component: File operation Version: 0.8.6 nightly build
Severity: major Keywords:
Cc: Operating System: Windows XP
Java version: 1.6

Description

When I go to delete a file by hitting <F8>, it does not delete. This is in 0.8.4 and is the nightly build, as of 7/17/09.

It does delete when I use <SHIFT>+<F8>, but then it bypasses the Recycle Bin and since we all sometimes delete the wrong file, this can be a real issue. :)

I doubt it's OS related, since <SHIFT>+<F8> works, but then again I'm not a programmer, so as requested, here are my specs:

I am running a Lenovo Y530-40516GU laptop
4 GB of RAM
WindowsXP 64 Bit w/SP2
nVidia 9300M GS
329 GB SATA HD

I don't know what else you might need. :)

Change History

  Changed 14 months ago by nicolas

  • component changed from Localization > English to File operation

  Changed 13 months ago by sombra

I can confirm this bug too. It seems that muCommander has some sort of problem interacting with the recycle bin in 64bit windows environments (Windows Vista Ultimate 64bit SP2 in my case).

  Changed 13 months ago by maxence

  • status changed from new to closed
  • resolution set to fixed
  • milestone set to 0.8.4

Thanks a lot for the report.

I have updated the JNA library, which I believe is the root cause of this issue, hoping that it will solve the problem. I have also added an error message "One or more files could not be moved to the trash".

Could either of you download the latest nightly build and try and reproduce the problem?

Cheers,
Maxence

  Changed 13 months ago by sombra

Hi,
I've downloaded the latest nightly build and the problem is still there, but at least there's a nice message now informing that the files could not be moved ;-)

As you said, I also think this is a JNA bug, I've been checking moveToTrash in WindowsTrash?.java and i've seen that Shell32.getInstance().SHFileOperation(fileop) returns error 87 (ERROR_INVALID_PARAMETER) in my machine.

Cheers.

  Changed 13 months ago by maxence

  • status changed from closed to reopened
  • resolution fixed deleted

Hey Sombra,
Thanks a lot for digging into this issue!

I've read several reports of people experiencing issues with SHFileOperation under Vista and Vista 64-bit specifically, but didn't come up with a potential explanation as to the particular problem we're experiencing.

Microsoft recommends using the IFileOperation interface over SHFileOperation under Vista. But on the other hand, SHFileOperation seems to work fine under Vista 32-bit, so I guess there is no reason why we couldn't use it under Vista 64-bit.

So all in all, I still think this is JNA-related. I'll try and re-generate the Shell32 JNA stubs using JNAerator, maybe something is incorrect in the current Shell32API interface.

I'm reopening this ticket until we come up with a fix. I'll definitely appreciate any further help you can provide as I don't have access to a Vista 64-bit machine.

Thanks again!

  Changed 13 months ago by sombra

Hi,
I've been checking JNA's source code and test units and their moveToTrash test also fails on my machine. For your information I've filed this issue:

https://jna.dev.java.net/issues/show_bug.cgi?id=126

Cheers.

  Changed 13 months ago by maxence

Great move! I've voted for the issue @dev.java.net. I haven't found a way to get CCed on the issue, but I'll be watching this ticket.

Thanks again,
Maxence

  Changed 13 months ago by sombra

For your information there's an update from the JNA guys:

"The FileUtilsTest? on 64-bit has never worked, although the failure reason seems
to have changed. It's not clear whether the failure is something in the JNA
mapping, or a required change in usage for 64-bit systems.

Feel free to submit a patch."

  Changed 13 months ago by maxence

Thanks for the update. I wish the JNA developer would know what's causing the failure, but at least the issue is acknowledged. Hopefully, someone will come up with a fix.

I've taken a look at Vista's IFileOperation interface and it seems very complicated to work with. We'll probably have to use it at some point, but I don't feel quite up for the task at the moment.

follow-up: ↓ 11   Changed 13 months ago by sombra

Yes, IFileOperation seems complicated and it would only solve half of the problem, because it does not exist on Windows XP (GiantWaffle? is using XP 64). Another option would be keep using SHFileOperation but calling it using JNI instead of JNA. It usually works fine but there is a lot more work involved and i don't know if you would like mantaining some C code.

When i have some time, I'm going to write a simple C test program just to make sure that SHFileOperation works ok on my machine. At this point i'm not even sure if that works.

in reply to: ↑ 10   Changed 13 months ago by maxence

Replying to sombra:

Yes, IFileOperation seems complicated and it would only solve half of the problem, because it does not exist on Windows XP (GiantWaffle? is using XP 64).

You're right, IFileOperation would not work under Windows XP 64-bit so it's not really a solution.

Another option would be keep using SHFileOperation but calling it using JNI instead of JNA. It usually works fine but there is a lot more work involved and i don't know if you would like mantaining some C code.

Yeah, I'd rather stay away from JNI as much as possible so as to not complicate the build process any futher, unless we're in a dead end with JNA.

When i have some time, I'm going to write a simple C test program just to make sure that SHFileOperation works ok on my machine. At this point i'm not even sure if that works.

Having a proof that SHFileOperation works as expected on Vista/XP 64-bit would be great indeed. Now that you mention it, I remember reading that SHFILEOPSTRUCT.fFlags behave somewhat differently under Vista, so the issue could very well be related to this.

Thanks again for your help on this!

  Changed 13 months ago by sombra

Hi,
I can confirm now that SHFileOperation works fine on Vista 64. I created 2 versions of my C test program, the first one was a 64bit native exe and the other one was a 32bit exe (so that it would run in WOW64 mode).
In both cases the deleted file is moved to the trash as expected so it must be something related to JNA.

Cheers

  Changed 13 months ago by maxence

Thanks for the quick follow up! So now we know for sure the issue is in JNA.

I'm not sure how to move forward with this as I'm not too familiar with the inner workings of JNA nor with Windows specifics...

Cheers.

  Changed 12 months ago by maxence

Hi again,
I have updated JNA to 3.2.2, which a number of fixes for structures. I'm not sure if that will help but the latest nightly has the new version if you feel like giving it a try.

Cheers,
Maxence

  Changed 11 months ago by sombra

Unfortunately it didn't work. Thanks for the attempt anyway.

Cheers

  Changed 11 months ago by maxence

  • summary changed from File Won't Delete in 0.8.4 to Recycle Bin not working on Windows 64-bit

  Changed 8 months ago by maxence

Alternatively, we could use a JNI to interact with the recycle bin, see:
http://www.jroller.com/ethdsy/entry/send_to_recycle_bin .

Vuze/Azureus uses JNI to call SHFileOperation:
http://fisheye1.atlassian.com/browse/~raw,r=1.24/azureus/azureus2/org/gudy/azureus2/platform/win32/access/impl/aereg.cpp

I've been wanting to stay away from JNI as much as possible as it would complicate the build process, but the inability to move to the trash is becoming a bigger problem as 64-bit versions of Windows are getting more widespread.

  Changed 7 months ago by sclebo05

  • version changed from 0.8.4 to 0.8.5 nightly build

Testing this bug on Windows 7 64 bit, hitting F8 does send file to the Recycle Bin with no problems. This works on the latest nightly build and a recent version of Java.

Info:

Version information

muCommander
Version: 0.8.5
Build date: 2010/02/11

Java
Runtime version: 1.6.0_17
VM name: Java HotSpot?(TM) Client VM
VM version: 14.3-b01
VM vendor: Sun Microsystems Inc.

OS
Name: Windows 7
Version: 6.1
Architecture: x86

Locale
Language: en
Country: US
Encoding: Cp1252

  Changed 6 months ago by maxence

Hey Josh, thanks for sharing this. Could it be that your Java Runtime is 32-bit ? On Mac OS X with a 64-bit processor and a 64-bit JVM, VM name shows "Java HotSpot?(TM) 64-Bit Server VM".

If that is the case, switching to a 32-bit JVM could be a workaround for this bug.

  Changed 6 months ago by sclebo05

You are correct - I was using 32 bit Java.

Could not move items to trash on 64 bit version:
Java
Runtime version: 1.6.0_18
VM name: Java HotSpot?(TM) 64-Bit Server VM
VM version: 16.0-b13
VM vendor: Sun Microsystems Inc.

"One or more files could not be moved to trash"

But had no problems on 32 bit version:

Java
Runtime version: 1.6.0_18
VM name: Java HotSpot?(TM) Client VM
VM version: 16.0-b13
VM vendor: Sun Microsystems Inc.

So in summary, I had to use the latest 32 bit version from the Sun(Oracle) site, namely jre-6u18-windows-i586.exe

Note: See TracTickets for help on using tickets.