for example i have an archive in a folder with special characters in its name like for example white space ampers&and paran(thesis) foo"bar" and so on, then the file is not found. other files can be opened in other programs, so thunar can handle such names. maybe ask benny how thunar escapes those special chars and returns the path. since both programs are for xfce, i assume they should work together ;> [] and + do work however.
You mean you drag a folder with special chars from thunar and drop it in xarchiver window, don't you ?
no, i just try to open an archive in the folder with xarchiver, but i get the "file does not exist" error.
I can't reproduce it. Can you please describe step by step how to reproduce this bug ?
just create a new folder in thunar and keep the default name (New Folder). then copy an archive (i've used a zip archive here) into this folder and try to open it with xarchiver by double clicking the file. now i get a little error window from xarchiver that says "The file doesn't exist!" and after that the xarchiver window is shown, but no file is loaded. when i cd into that "New Folder" dir in a terminal and then run "xarchiver foo.zip" it works. i have xarchiver 22087 and thunar 22090.
The matter gets complicated. I added from Thunar the path to xarchiver so to open the archives with Xarchiver and I get this error message from Thunar: Failed to add new application "xarchiver". Failed to execute child process "update-desktop-database" (No such file or directory). How can fix it ? I use zenwalk as distro, where can I find this "update-desktop-database" ??
in arch it is in the desktop-file-utils package: http://www.archlinux.org/packages.php?id=5575 http://freedesktop.org/software/desktop-file-utils/
Ok, got the file but I still can't reproduce the bug. The archive is correctly opened when double clicking on its icon from the "New Folder" directoty in Thunar. Can you please try the current svn revision please ?
tried with xarchiver 22153 but the problem remains.
How can we solve this bug ? On my linux box double clicking on an archive contained in a directory whose name contains spaces is correctly loaded, on yours not ! Mmm, could you please add the following lines after line 277 in src/callbacks.c and paste here the output please ? g_message (archive->path); g_message (archive->escaped_path);
done that. i don't get any output at all. btw when i didn't cd into the "New Folder" but try to open the archive from the terminal like xarchiver New\ Folder/foo.zip then the archive isn't found aswell. so i think it's not thunar related. when i'm in the same folder, then i get ** Message: foo.zip ** Message: foo.zip as output.
Ok, the matter complicates always more. Can you remove the previous g_message and put this one in main.c after the opening bracket at line 153: g_message ("%s %s",argv[1],argv[2]); and post the output again ? Thank you for your patience.
did you mean the closing bracket in line 152? //This to open the archive from the command line if ( argc == 2) { gchar *dummy = g_strdup(argv[1]); xa_open_archive ( NULL , dummy ); } g_message ("%s %s",argv[1],argv[2]); gtk_main (); that's the way i have it now, i think that was correct. baze ~ $ xarchiver New\ Folder/foo.zip ** Message: New Folder/foo.zip (null)
No, I meant the opening bracket not the closing one, anyway it's the same. What if you double click on the archive in the directory whose name contains special chars, what happens ? I mean the output in the console.
then the full path is returned: ** Message: /home/baze/New Folder/foo.zip (null)
Baze, the filename is escaped in src/callbacks.c at line 277, the filename is passed to a routine who escapes chars like the space, the ampersand ecc ecc. The filename on the cmd-line is duplicated at main.c line 154: gchar *dummy = g_strdup(argv[1]); and then is sent to the function xa_open_archive in callbacks.c line 260 who then escapes it as I wrote above. I can't fix it since it works on my sistem. Can you try on another Linux box ?
no, i don't have access to another box atm, sorry. i'll just avoid putting archives in folders with bad names for the time ;)
Fixed in svn r22155.
closing