Thanks for the pointer!
From that page I can see "cr_delete_scheduled_files" is correctly scheduled, and that when a file is deleted, "cr_files_to_delete" table is updated correctly.
I think I have found my problem: as my application manages music playlists composed by many files, I developed a script which allows for the uploading of a big zip file to the server, containing many mp3s.
As something can go wrong during the insertions of the songs (because of wrong format or other issues), this operation can fail when some of the files were already put into content repository. As the operation is made into a db_transaction, all changes to the db are rolled back, but the same doesn't happen to the physical files in content-repository, which will remain there forever (no explicit deletion issued, so no entry into "cr_files_to_delete").
Would it be reasonable to change "cr_delete_scheduled_files" so it sweeps every file not having an entry into content repository tables? It would be more aggressive, but we could make it parametrical...
