gnome-search-tool: delete of file fails - Name too long

[Grek-336]

Binary package hint: gnome-utils

Some times the remove of files fails with the error message: Can't move in trash Name too long.

When I open the folder where the files are, I can delete them without any problem.

Attachment: A screenshot of the problem.

[Grek-336 (kult01)]

I have found some very long filenames in my trash. I think that this is the main problem.

[Grek-336 (kult01)]

Ubuntu 7.10 gutsy
gnome-utils 2.20.0.1-0ubuntu1

[Grek-336 (kult01)]

I have found that the building for new names of duplicate File Names for the Trash is wrong

SmallCover
SmallCover (Kopie)
SmallCover (noch eine Kopie)
SmallCover (3. Kopie)
SmallCover (4. Kopie). Kopie)
SmallCover (5. Kopie). Kopie). Kopie)
SmallCover (6. Kopie). Kopie). Kopie). Kopie)
...
SmallCover (22. Kopie). Kopie). Kopie). Kopie). Kopie). Kopie). Kopie). Kopie). Kopie). Kopie). Kopie). Kopie). Kopie). Kopie). Kopie). Kopie). Kopie). Kopie). Kopie). Kopie)

[Pedro Villavicencio (pedro)]

thanks for your report, that works fine for me with hardy, can you test the same there? thanks.

[Grek-336 (kult01)]

I can reproduce the failure in a Hardy VirtualBox VM. Remember that I use GNOME with German Language Settings.

I have found that gnome-search-tool (aka "Datei suchen") not use the new Trash in Hardy (~/.local/share/Trash/files). It use the old Trash (~/.Trash)

A Screenshot to documentary the failure in Hardy.

My VM Hardy have all Updates installed. It is a clean Installation. The only additional installations are they to compile the Guest addionals for VirtualBox.

Is the use of the old Trash a new bug of the gnome-search-tool?

[Sebastien Bacher (seb128)]

could you describe easy steps to trigger the issue? the trash directory is an another bug

[Grek-336 (kult01)]

I will try easy instruction to reproduce the bug

1) Create some files with the same name
2) Search for this files with (german) "Orte->Dateien suchen" (I think File search in englisch) and delete them (Not in a nautilus windows! You must do it in the windows from gnome-search-tool).

Example:

1) create a file "neue Datei". Search for it with the gnome-search-tool and delete them. In the Trash you have a file with the name "neue Datei".
2) Do the same and in the Trash you have a file with the name "neue Datei (Kopie)"
3) Do the same and in the Trash you have a file with the name "neue Datei (noch eine Kopie)"
4) Do the same and in the Trash you have a file with the name "neue Datei (3. Kopie)"
5) Do the same and in the Trash you have a file with the name "neue Datei (4. Kopie). Kopie)"
6) Do the same and in the Trash you have a file with the name "neue Datei (5. Kopie). Kopie). Kopie)"
...
xx) Do the same and in the Trash you have a file with the name "neue Datei (xx. Kopie). Kopie). Kopie)..."
xx+1) Do the same and you become an error

Each file name is in the german Version is length(". Kopie)")=8 longer than the file name before & 255/8 = 31.875. -> The delete of the 32. (or less) file with the same name will make the "Name is to long" error.

Remember this bug is only in gnome-search-tool. When I delete the files in nautilus the creating of the file names for the Trash is correct ("neue Datei", "neue Datei (Kopie)", "neue Datei (noch eine Kopie)", "neue Datei (4. Kopie)", neue Datei (5. Kopie) ...
But when you delete them in gnome-search-tool you become ("neue Datei", "neue Datei (Kopie)", "neue Datei (noch eine Kopie)", "neue Datei (4. Kopie). Kopie)", "neue Datei (5. Kopie). Kopie). Kopie)", ...) and than an error when the File name is too long (I think more than 255 characters).

[Sebastien Bacher (seb128)]

what locale do you use? the copy label has no such issue on my intrepid installation. also what filesystem is used on the drive where you have your example?

[Grek-336 (kult01)]

my locale are:

michael@michael-desktop:~$ locale
LANG=de_DE.UTF-8
LC_CTYPE="de_DE.UTF-8"
LC_NUMERIC="de_DE.UTF-8"
LC_TIME="de_DE.UTF-8"
LC_COLLATE="de_DE.UTF-8"
LC_MONETARY="de_DE.UTF-8"
LC_MESSAGES="de_DE.UTF-8"
LC_PAPER="de_DE.UTF-8"
LC_NAME="de_DE.UTF-8"
LC_ADDRESS="de_DE.UTF-8"
LC_TELEPHONE="de_DE.UTF-8"
LC_MEASUREMENT="de_DE.UTF-8"
LC_IDENTIFICATION="de_DE.UTF-8"
LC_ALL=
michael@michael-desktop:~$

The Filesystem is ext3

I have make a screencast in my VirtualBox Hardy VM. Filesystem and locale is the same

[Sebastien Bacher (seb128)]

confirming, that's really a corner case though and should be fixed when gnome-search-tool will use gio

[Sebastien Bacher (seb128)]

there is http://bugzilla.gnome.org/show_bug.cgi?id=524574 upstream about using gio

[John Doe (jodo-deactivatedaccount)]

Still the same in Intrepid. I'm using german locale, too. I wanted to delete all covers from my Musicfolder, about 120 Files, all Named "folder.jpg". Error message was the same. As I figured out, the error occured after deleting 32 Files.

Will this be fixed on the Final?

[Alexander Kallenbach (kallenbachalex)]

I can confirm this bug.

[Sebastien Bacher (seb128)]

the bug has been fixed upstream now

[Launchpad Janitor (janitor)]

This bug was fixed in the package gnome-utils - 2.27.1-0ubuntu1

---------------
gnome-utils (2.27.1-0ubuntu1) karmic; urgency=low

  * New upstream version: (LP: #372168)
    - [build] Fix zlib support
    - [dictionary] Port to GtkBuilder
    - [gsearchtool] Minor logic fix
    - [gsearchtool] Typo fix
    - [gsearchtool] Sync open with menu with nautilus
    - [gsearchtool] clean up code
    - [doap] Add project description
    - Move ChangeLog out of the way
    - [build] Generate ChangeLog on dist
    - [build] Generate ChangeLog from the import tag
    - [docs] Add documentation on commit practises
    - [build] Remove the spec file
    - [gitignore] Create ignore file
    - [build] Massive update to the configure template
    - [docs] Update the HACKING file
    - [doap] Add download-page and change shortdesc
    - [build] Export the MAINTAINER_CFLAGS variable
    - [build] Clean up gdict Makefile template
    - [gitignore] Add intltool droppings
    - [gitignore] Add gnome-dictionary ignore file
    - Move gnome-dictionary ChangeLog
    - [build] Use Shave
    - [build] Show generation rules
    - [docs] The help XML file should not be committed
    - [gitignore] Add ignore file for sub-modules
    - [gitignore] Ignore all m4 files that we don't control
    - [build] Fix AS_CASE error condition
    - [doap] rdf:resource requires a URI
    - Fix bug #580139 - invalid help uri (LP: #342753)
    - Fix bug #581002 - Baobab crashes when scan is pointed to a de-selected
       mount point (LP: #369740 fixes also LP: #248005)
    - doap: Add desktop category
    - Fix compiler warning
    - Rework monitoring of the home file dir
    - Remove leftover declaration
  * Rebase on debian 2.24.1-2, remaining ubuntu changes:
    - debian/control{.in}
       - update build-depends for new version
       - replace vcs-tag with launchpad bzr tag
       - libgdict and gnome-utils replace the ubuntu packages
    - debian/watch: Check upstream development versions, too.
    - debian/rules: Update to properly use cdbs, since it uses parts of cdbs
      already; this gives us full translation handling/stripping without
      replicating all those rules; it also drops a lot of obsolete stuff.
      Define gnome.mk after the standard rules so the schemas registration works
    - debian/*.files: Rename to *.install, and drop mixed
      dh_movefiles/dh_install usage.
    - debian/patches
      - Refresh existing patches to apply to new version
      - drop 01_logview_gksu.patch, we have the admin group for this
      - drop 03_screenshot_xinerama.patch, applied upstream
      - add 04_lpi.patch and 99_autoconf.patch to provide lpi
      - add 05_menu_changes.patch for ubuntu menu simplification
  * Fixes at least:
      - use new gvfs-trashsystem (LP: #207434)
      - don't fail search on apostrophe in filename (LP: #202111)
      - don't fail search on invalid encoding (LP: #247299)
      - find also hidden files (LP: #275535)
      - fix throbber rest icon and animation warning (LP: #338848)
        (LP: #352602)
      - scroll to bottom of logfiles automatically (LP: #346558)
      - don't always scan homefolder (LP: #36...