Option to remove attachments that are no longer linked

I think I disagree if I understand the bug correctly. I have several pages that I treat as top level and don't necessarily have anything linking to them. I also like Zim's directory structure (it gives one and idea to have your personal file system entirely wiki-ised in a sense, to add notes about what things are) and I and don't think I want zim automatically deleting things or moving them. A checkbox for other people to activate this feature won't bother me though of course.

On Thu, Dec 10, 2009 at 10:28 PM, dagurasu wrote:

> I think I disagree if I understand the bug correctly. I have several
> pages that I treat as top level and don't necessarily have anything
> linking to them.

The bug report talks about attachments that are not linked, not the pages
itself.
(So by files I understand any file that is not a page.)

> I also like Zim's directory structure (it gives one
> and idea to have your personal file system entirely wiki-ised in a
> sense, to add notes about what things are) and I and don't think I want
> zim automatically deleting things or moving them. A checkbox for other
> people to activate this feature won't bother me though of course.
>

In the new python branch if you delete a page, all pages and attachments
below that page are also removed. (Of course after a warning dialog.) Which
makes behavior more consistent. If you just wan to delete the page itself
and none of it's children, you can always just remove the text in the file.

For attachments that are under a valid page, but are just not linked anymore
it is more difficult to have a sane default. I agree you don't want to start
deleting them without option to turn that off. Maybe there needs to be a
tool to "clean" a notebook, which will present the user with a list of
unlinked attachments ?

Regards,

Jaap

Sorry, I screwed up, I didn't intend to nominate this bug for Perl-zim release. But I also do not know how to undo that.

Just changed title back. No problem.

Just to be clear, this request is not specific to the perl version. Also in the python branch you can have attachments that are not linked at all, but also not cleaned up.

My opinion is that the best way to solve this is to have a menu item "Tools"->"Cleanup Notebook" that presents the user with a list of attachments that could be deleted with checkboxes for each item and a "delete" button.

Automatically deleting attachments when they are not linked may be a bit to aggressive.

From duplicate:

"""
If I create a new equation using the Equation Editor plugin and then subsequently delete the equation from the page, the actual .png and .tex files are left behind and not deleted.

I can understand them being kept temporarily (because of UNDO/REDO), but it would be good if they could be deleted when Zim is closed.
"""

the following patch adds a dialog to find, open and delete orphaned files to the Tools menu.

Thanks smu, patch looks quite good. Just two small comments: I would use the "link_type" function (from zim.parsing if I'm not mistaken) to check links are file links versus other link types. Second comment is that I miss the copyright statement for the new module. Btw, what is your real name ?

Regards,

Jaap

On Thu, Jan 13, 2011 at 10:05:43AM -0000, Jaap Karssenberg wrote:
> Thanks smu, patch looks quite good. Just two small comments: I would
> use the "link_type" function (from zim.parsing if I'm not mistaken) to
> check links are file links versus other link types. Second comment is
> that I miss the copyright statement for the new module.

Ok, new patch with with link_type and copyright statement attached.

> Btw, what is your real name ?

it's Stefan Muthers :)

best regards,
 Stefan

...and the attachment.

I have often intentionally files in notebook folders that are not linked themselves (but normally I do use a link to open the folder). So I certainly think the suggestion of Jaap for a "Tools"->"Cleanup Notebook" option is a good one.

It would be nice if that tool could be applied to parts of the Zim notebook, i.e., to clean out one node (and all sub-notes of that node) only. Alternatively, if the dialog lists all orphaned files, does it (or could it if not) include the path to the folder (possibly relative to the note root)?

I would like to try this out the above mentioned patch, but I am not sure how to apply this patch.

Regards,

Paulo

Hi Paulo,

On Tue, Jan 18, 2011 at 03:14:13PM -0000, pvanb wrote:
> I have often intentionally files in notebook folders that are not linked
> themselves (but normally I do use a link to open the folder). So I
> certainly think the suggestion of Jaap for a "Tools"->"Cleanup Notebook"
> option is a good one.
>
> It would be nice if that tool could be applied to parts of the Zim
> notebook, i.e., to clean out one node (and all sub-notes of that node)
> only.

this is not possible with the current patch, is is applied to the
compete notebook, ...

> Alternatively, if the dialog lists all orphaned files, does it (or
> could it if not) include the path to the folder (possibly relative to
> the note root)?

... presents a list of filenames and the corresponding pagenames (of the attachment
folder) and you can select files individually.

>
> I would like to try this out the above mentioned patch, but I am not
> sure how to apply this patch.

Do you use the development version of zim or version 0.49? Linux or
Windows?

In the development version under linux you can apply the patch as
follows (in a terminal):

cd zim/source/directory
patch -p0 < path/to/the/patch
./zim.py

best regards,
 Stefan

just discovered pylint and found, that I had overseen some unused import
statements.

On Mon, Jan 17, 2011 at 07:14:16PM -0000, smu wrote:
> ...and the attachment.
>
>
> ** Patch added: "cleannotebook2.diff"
> https://bugs.launchpad.net/bugs/416859/+attachment/1797047/+files/cleannotebook2.diff
>
> --
> You received this bug notification because you are a bug assignee.
> https://bugs.launchpad.net/bugs/416859
>
> Title:
> Files without links should be removed
>
> Status in Zim desktop wiki:
> In Progress
>
> Bug description:
> In Zim 0.27 files that are attached stay there. It would be nice that
> if all links to those files are gone, the file would be automatically
> removed or transferred into some kind of wastebin thingy.
>
>
>

Was about to merge this patch but encountered an error when opening my debug notebook:

Traceback (most recent call last):
  File "/home/jaap/code/pyzim-trunk/zim/gui/__init__.py", line 594, in _action_handler
    method(*arg)
  File "/home/jaap/code/pyzim-trunk/zim/gui/__init__.py", line 1211, in clean_notebook
    CleanNotebookDialog(self).run()
  File "/home/jaap/code/pyzim-trunk/zim/gui/cleannotebook.py", line 184, in __init__
    self.treeview = OrphanedFilesTreeView(ui)
  File "/home/jaap/code/pyzim-trunk/zim/gui/cleannotebook.py", line 115, in __init__
    self.orphaned_files = get_orphaned_files(ui.notebook)
  File "/home/jaap/code/pyzim-trunk/zim/gui/cleannotebook.py", line 83, in get_orphaned_files
    if not shortfile in linked_files[pagename]:
KeyError: u'Album'

Would have debugged it myself, but too late on the evening and will not have much time for code until the end of the week.

Will look into this within the next days.

On Tue, Jan 25, 2011 at 09:23:08PM -0000, Jaap Karssenberg wrote:
> Was about to merge this patch but encountered an error when opening my
> debug notebook:
>
> Traceback (most recent call last):
> File "/home/jaap/code/pyzim-trunk/zim/gui/__init__.py", line 594, in _action_handler
> method(*arg)
> File "/home/jaap/code/pyzim-trunk/zim/gui/__init__.py", line 1211, in clean_notebook
> CleanNotebookDialog(self).run()
> File "/home/jaap/code/pyzim-trunk/zim/gui/cleannotebook.py", line 184, in __init__
> self.treeview = OrphanedFilesTreeView(ui)
> File "/home/jaap/code/pyzim-trunk/zim/gui/cleannotebook.py", line 115, in __init__
> self.orphaned_files = get_orphaned_files(ui.notebook)
> File "/home/jaap/code/pyzim-trunk/zim/gui/cleannotebook.py", line 83, in get_orphaned_files
> if not shortfile in linked_files[pagename]:
> KeyError: u'Album'
>
> Would have debugged it myself, but too late on the evening and will not
> have much time for code until the end of the week.
>
> --
> You received this bug notification because you are a bug assignee.
> https://bugs.launchpad.net/bugs/416859
>
> Title:
> Files without links should be removed
>
> Status in Zim desktop wiki:
> In Progress
>
> Bug description:
> In Zim 0.27 files that are attached stay there. It would be nice that
> if all links to those files are gone, the file would be automatically
> removed or transferred into some kind of wastebin thingy.
>
>
>

forgot to check for pages without content but attachments.
new patch attached.

Will need to work a bit more on this. Current method to check linked files assumes that files are only linked from the page where they are attached. However other pages could still link an attachment. Will have a further look tomorrow.

On Sun, Jan 30, 2011 at 09:28:35PM -0000, Jaap Karssenberg wrote:
> Will need to work a bit more on this. Current method to check linked
> files assumes that files are only linked from the page where they are
> attached. However other pages could still link an attachment. Will have
> a further look tomorrow.

right, this is missing.
A possibility would be to convert the links and the file paths to
absolute links/paths and compare them.
I can give it a try, but I can not promise to do it in the next days.

best regards,
 stefan

On Sun, Jan 30, 2011 at 10:20:10PM -0000, smu wrote:
> A possibility would be to convert the links and the file paths to
> absolute links/paths and compare them.

path for this is attached.

best regards,
 stefan

Did some further tweaks and committed as rev343 - thanks a lot Stefan!

On Mon, Jan 31, 2011 at 08:26:14PM -0000, Jaap Karssenberg wrote:
> Did some further tweaks and committed as rev343 - thanks a lot Stefan!

Something does not work atm., the notebook.resolve_file(link) does not
resolve the real path to the attachment folder.

The patch attached fixes this, but it is a step back, maybe you find a
nicer solution.

best regards,
 stefan

No, we do need to use resolve_file, if only because otherwise you will
wrongly interpret links to the document dir or to absolute paths,
share drives etc. Not every link is relative.

Probably I forgot to give the page as argument to the resolve_file method.

Would be useful to have a test case to prevent mistakes.

On Tue, Feb 01, 2011 at 11:25:42AM -0000, Jaap Karssenberg wrote:
> No, we do need to use resolve_file, if only because otherwise you will
> wrongly interpret links to the document dir or to absolute paths,
> share drives etc. Not every link is relative.

good point.

> Probably I forgot to give the page as argument to the resolve_file
> method.
>
> Would be useful to have a test case to prevent mistakes.

I can care about that.

best regards,
 stefan

Afraid I found another complication. We forgot to take into account that source files for e.g. latex equations, diagrams etc. are not linked explicitly, so the dialog will show them as orphaned. Unless we can think quickly of a robust way to detect this I afraid I'll have to disable this feature for the upcoming release and pick it up again in the next development cycle.

Hi Jaap,

On Mon, Feb 07, 2011 at 08:07:44PM -0000, Jaap Karssenberg wrote:
> Afraid I found another complication. We forgot to take into account that
> source files for e.g. latex equations, diagrams etc. are not linked
> explicitly, so the dialog will show them as orphaned. Unless we can
> think quickly of a robust way to detect this I afraid I'll have to
> disable this feature for the upcoming release and pick it up again in
> the next development cycle.

A quick, but rather static solution is to check, if an linked image
has a type tag and add the corresponding source files ('diagram\d*.dot',
'equation\d*.tex',...) to the list of linked files.

A patch for this is attached, I included the types diagram, euqation and
gnu_r_plot, anything that I forgot?

best regards,
 stefan

On Tue, Feb 8, 2011 at 3:55 PM, smu <email address hidden> wrote:
> A quick, but rather static solution is to check, if an linked image
> has a type tag and add the corresponding source files ('diagram\d*.dot',
> 'equation\d*.tex',...) to the list of linked files.
>
> A patch for this is attached, I included the types diagram, euqation and
> gnu_r_plot, anything that I forgot?

That is a way to do it, but it is a hack. Plugins can register new
types of source files for images, so we can never be sure about the
full list of supported formats. Maybe just exclude any file that has a
image file of the same name that is used.

-- Jaap

On Wed, Feb 09, 2011 at 11:32:43AM -0000, Jaap Karssenberg wrote:
> On Tue, Feb 8, 2011 at 3:55 PM, smu <email address hidden> wrote:
> > A quick, but rather static solution is to check, if an linked image
> > has a type tag and add the corresponding source files ('diagram\d*.dot',
> > 'equation\d*.tex',...) to the list of linked files.
> >
> > A patch for this is attached, I included the types diagram, euqation and
> > gnu_r_plot, anything that I forgot?
>
> That is a way to do it, but it is a hack. Plugins can register new
> types of source files for images, so we can never be sure about the
> full list of supported formats.

yes, that is what I meant with 'static'. Do you have a better idea? Is
it possible to query a list of source files and types somehow?

> Maybe just exclude any file that has a
> image file of the same name that is used.

But it would be save to do this only, when the attrib['type'] is
present, am I correct?

best regards,
 stefan

Temporarily disabled this feature for 0.50 release

I found that I can query a list of image-plugins via ui.plugins, and if
the source files basename and the type attribute would be defined in
the PluginClass, it would be easy to exclude the source files from
deletion. That would mean, we have to change the 3 existing plugins that
generate images.

The alternative would keep everything that matches imagename.*, but I
would not call this a nice solution.

any other ideas?

best regards,
 stefan

On Thu, Feb 17, 2011 at 7:40 PM, smu <email address hidden> wrote:
> any other ideas?

I have been thinking how to change the format of these image links to
explicitly define their source type. Say e.g. :

 {{equation001.png?type=equation&src=tex}}

would signify that this file uses equation001.tex as source code.

THis is more robust than trusting on the plugins registering the
format. I don't want to throw away the wrong files just because I had
the plugin disabled.

Would require a notebook update to fix all the existing pages.

Also thinking that it may be good to have trash implementation for
this stuff. But that is a more general item out of scope of this
particular feature.

-- Jaap

On Thu, Feb 17, 2011 at 10:59:28PM -0000, Jaap Karssenberg wrote:
> On Thu, Feb 17, 2011 at 7:40 PM, smu <email address hidden> wrote:
> > any other ideas?
>
> I have been thinking how to change the format of these image links to
> explicitly define their source type. Say e.g. :
>
> {{equation001.png?type=equation&src=tex}}
>
> would signify that this file uses equation001.tex as source code.
>
> THis is more robust than trusting on the plugins registering the
> format. I don't want to throw away the wrong files just because I had
> the plugin disabled.

I thought it would be possible to check for a format definition, when
the plugin calls self.register_image_generator_plugin.
But your solution would be more robust for plugins that are not longer
used.

>
> Would require a notebook update to fix all the existing pages.

How would this update process work? Define a new wiki format number and
rewrite the links, when it is lower? Or this this to complicated?
Are there any examples for something similar in the zim code?

best regards,
 stefan

> How would this update process work? Define a new wiki format number and
> rewrite the links, when it is lower? Or this this to complicated?
> Are there any examples for something similar in the zim code?

Yeah zim has an update function for older formats that still assume all indented text is verbatim. So we can use the same to update this as well. Will indeed require new notebook format number.

Currently working on branch for inline objects. Will also work in image generators in that context. Now looking to put the generated images in a cache folder inside the notebook (similar to how thumbnails are stored). So only source text will be in attachment folder. Then instead of linking the image we link the source directly while giving the type of the generator.

So {{equation001.png?type=equation}} will become {{equation001.tex?type=equation}}

That will make it much easier to do this attachment cleanup without having to know anything about the plugins handling theses files.

In addition I also want to make inlining the source the default, so zim will generate much less files for equations etc. ("Inlining" means there will be a block of latex in the wiki text instead of being given as a separate file.)

On Mon, Feb 28, 2011 at 05:08:16PM -0000, Jaap Karssenberg wrote:
> > How would this update process work? Define a new wiki format number and
> > rewrite the links, when it is lower? Or this this to complicated?
> > Are there any examples for something similar in the zim code?
>
> Yeah zim has an update function for older formats that still assume all
> indented text is verbatim. So we can use the same to update this as
> well. Will indeed require new notebook format number.

ok, thanks for the explanation.

> Currently working on branch for inline objects. Will also work in image
> generators in that context. Now looking to put the generated images in a
> cache folder inside the notebook (similar to how thumbnails are stored).
> So only source text will be in attachment folder. Then instead of
> linking the image we link the source directly while giving the type of
> the generator.

ok and the cache folder is persistent or are all image recreated after
a restart of zim? I am asking, because a new image generation would
mean, that images from generators that are not available (e.g. because
the notebook is used on windows), could not be displayed.

best regards,
 stefan

On Tue, Mar 1, 2011 at 2:32 PM, smu <email address hidden> wrote:
>> Currently working on branch for inline objects. Will also work in image
>> generators in that context. Now looking to put the generated images in a
>> cache folder inside the notebook (similar to how thumbnails are stored).
>> So only source text will be in attachment folder. Then instead of
>> linking the image we link the source directly while giving the type of
>> the generator.
>
> ok and the cache folder is persistent or are all image recreated after
> a restart of zim? I am asking, because a new image generation would
> mean, that images from generators that are not available (e.g. because
> the notebook is used on windows), could not be displayed.

Cache would be semi-persistent, so we leave the images there and they
are available even if the plugin is not, however they may get cleaned
up whenever the user wants to reclaim some space.

I can imagine a scheduled cache cleanup, maybe integrated into the
index update. Just remove all cached images for which the source file
went missing. This should be triggered after running the "cleanup
notebook" dialog.

-- Jaap

On Tue, Mar 01, 2011 at 02:14:22PM -0000, Jaap Karssenberg wrote:
> On Tue, Mar 1, 2011 at 2:32 PM, smu <email address hidden> wrote:
> >> Currently working on branch for inline objects. Will also work in image
> >> generators in that context. Now looking to put the generated images in a
> >> cache folder inside the notebook (similar to how thumbnails are stored).
> >> So only source text will be in attachment folder. Then instead of
> >> linking the image we link the source directly while giving the type of
> >> the generator.
> >
> > ok and the cache folder is persistent or are all image recreated after
> > a restart of zim? I am asking, because a new image generation would
> > mean, that images from generators that are not available (e.g. because
> > the notebook is used on windows), could not be displayed.
>
> Cache would be semi-persistent, so we leave the images there and they
> are available even if the plugin is not, however they may get cleaned
> up whenever the user wants to reclaim some space.
>
> I can imagine a scheduled cache cleanup, maybe integrated into the
> index update. Just remove all cached images for which the source file
> went missing. This should be triggered after running the "cleanup
> notebook" dialog.

but do we still need a cleanup notebook dialog when the source inlined
and the images lay in the cache directory?

On Tue, Mar 1, 2011 at 5:22 PM, smu <email address hidden> wrote:
> but do we still need a cleanup notebook dialog when the source inlined
> and the images lay in the cache directory?

The use case indeed becomes much smaller, but might still be used
every now and then. Maybe offer it as a plugin then ? Or try to
integrate with the attachment browser plugin, we could display
backlinks to attachments somewhere.

-- Jaap

On Tue, Mar 01, 2011 at 05:54:19PM -0000, Jaap Karssenberg wrote:
> On Tue, Mar 1, 2011 at 5:22 PM, smu <email address hidden> wrote:
> > but do we still need a cleanup notebook dialog when the source inlined
> > and the images lay in the cache directory?
>
> The use case indeed becomes much smaller, but might still be used
> every now and then. Maybe offer it as a plugin then ? Or try to
> integrate with the attachment browser plugin, we could display
> backlinks to attachments somewhere.

Also thought about a delete functionality in the attachment browser.
It would be nice, to mark orphaned attachments by a special emblem, but
therefore it would be useful to have a list of orphaned attachments
stored somewhere. Checking the whole notebook everytime the attachments
widget is opened would be probably to complicated.

best regards,
 stefan

On Thu, Mar 3, 2011 at 2:54 PM, smu <email address hidden> wrote:

> Also thought about a delete functionality in the attachment browser.
> It would be nice, to mark orphaned attachments by a special emblem, but
> therefore it would be useful to have a list of orphaned attachments
> stored somewhere. Checking the whole notebook everytime the attachments
> widget is opened would be probably to complicated.
>

Sounds like we will need a full index table of all files in the notebook
structure, and their links. Or is there an easier way to get this ?

-- Jaap

To further explore the option of flagging unlinked files in the attachment browser plugin I think we need two components:

1/ index of files and links - can be added to current indexer
2/ way to draw icons with an emblem on them

For 2. the GIO library has the required functionality. Would like to use that library anyway to get proper mimetype icons etc.

See http://library.gnome.org/devel/pygobject/stable/gio-class-reference.html

On Tue, Mar 08, 2011 at 04:24:32PM -0000, Jaap Karssenberg wrote:
> To further explore the option of flagging unlinked files in the
> attachment browser plugin I think we need two components:
>
> 1/ index of files and links - can be added to current indexer
> 2/ way to draw icons with an emblem on them

sorry for the late reply. Yes, probably an index table would be the
best, but for the emblems in the attachment browser, a table of file
links would be enough. When the attachment browser is opened, we could
check the existing files, if links to these file exist.

best regards,
 stefan

> Files without links should be removed

I think this may be true only for zim's own files.
I.e. the said source and picture files of plugings. However, I like that you are moving them out of the way. This makes zim's directory tree even nicer, it would be just awesome to be able safely store other project files besides notes and explicit attachments within that tree as well.

The directory tree created with zim tends to resemble your tasks and projects perfectly.

The index of files and links you devised, could be usefull to
* (optionally) ask if a file should be removed if the last link is removed.
* only delete a directory branch if it does not contain additional user files
* only delete zim linked files
* swichable "attachment" browser: show only the attached files, or all files.
* if viewing all files, link files already stored the the directory into wiki page (drag and drop?).
...

> In the new python branch if you delete a page, all pages and attachments
below that page are also removed. (Of course after a warning dialog.)

Maybe delete branch or delete namespace would be more descriptive?
The warning, or already the menu, could maybe offer to select what to delete: complete directory branch with all contained files, only the zim pages, files becoming unlinked without these pages, delete (empty) only the top page/node selected, or put a ".zimignore" in that directory branch?

Besides: When zim deletes a directory tree, and it contains a symlink to some other directory, does it only delete the symlink, or the other complete directory as well?

and the other way around:

* when a file is deleted (with the attachment browser or externally) remove/mark/list the dead links?

Would this be a more intuitive naming: instead of delete/rename/move a page, delete/rename/move a node or directory vs. a page?

I do increasingly like the idea of using zim on a directory tree that can also be used by other programms (e.g. $HOME or another subdir).

As the attachment browser is pretty much a file browser, maybe embed one and just make it hide the zim files by default, since they are shown and edited in zim's other panes.

(Rethinking the idea of .zimignore files to make existing directories not show up in zim: It's bad practice to clutter directories with files like this. Instead, zim could just ignore all directories for which no corresponding .txt file exists. Removing a page/node (.txt file) would then cause zim to ignore the directory, while an empty .txt file would keep any .txt file contained in the subdirectory visible in zim.

Zim's note deletion functionality could operate according to whether one chose/selected to only clear a single note, delete all sub-notes as well, delete linked files in the directory that will become unlinked as well, or actually completely delete the whole directory.

Zim's link deletion functionality could ask whether to delete a file that will become unlinked.

@ceg: when talking about the attachment browser please use the latest
version of zim (0.50), e.g. it already hides zim page files by default

Sorry, I wasn't clear enough in expressing that part of the idea.
Was the rest ok?

I have 0.50 installed, I hope my inserts can clear it up:

"As the attachment browser is pretty much a file browser, maybe [instead of adding deletion and other features to zim's attatchment browser plugin and effectively reimplementing another file browser] embed [a readily existing file browser widget] one and just make it [the generic file browser] hide the zim files by default, since they are shown and edited in zim's other panes."

Directories not related to zim, i.e. without a corresponding .txt file, might also be hidden in that generic file browser widget by default. However, an option to show all files would be usefull to create notes and links relating to the files under one's $HOME for example. (And having the note stored right in the same place.)

When the last link to a file is deleted, zim could ask whether to also delete the _once_linked_ file. It would make sense to select the deletion for files like screenshots, only relevant for the note that is to be deleted. However, to make it safe to share the directory tree created or used in zim with other apps, zim should always allow to leave unlinked/unrelated files untouched by default.

For example, if a note containing subnotes is deleted, zim could ask about unlinked files as well as sub-pages.

Also delete?:
[] all sub-pages
[] files becoming unlinked. (list derived from an index)
[] all files stored under this directory (list as in zim 0.5)

If 3rd is checked delete the .txt file and its directory completely.
If nothing or only 2nd is checked, just empty the page.
If "all subpages" is checked, recursively delete all text/x-zim-wiki *.txt files (i.e. including the top note to delete, causing zim to)
If "files becoming unlinked" is checked, delete those.
Directories that contained only zim files and are now empty, can be deleted. Directories that where already empty before and directories containing other files are kept.

oops, incomplete 5th line from the end of my last post:
>(i.e. including the top note to delete, causing zim to)
... consider it a non-zim directory it will hide by default)

 found gnome's nautilus browser actually already has a rudimentary "notes" feature availabe in its left side pane (possibly only with some extra package installed).

I had imagined a navigation like that. Thinking of zim panes in a file browser like nautilus or a file browser pane in zim.

@ceg: thanks for your comment, but please don't revise the title of the report like this for a report owned by someone else

All right, just wanted the title to actually represent the conclusions of the discussion I had read through:

* clean notebook function now of less use
   (zim files are cached and hidden)
* linked files index needed to:
  * optionally delete files / directories bocoming unlinked
  * provide option to delete files in attachment (file) browser

See also duplicate bug #898157

I hate to be a bother but what is the status on this? I ask because I update my notes and sometimes I delete an image or an equation and it appears the files are still kept there.

+signed

Hi all,

I couldn't find this option on Zim (0.72.0-1), can some one please confirm is this feature is live (maybe using other bugtrack id).

Thank you

All feature requests are now managed there: https://github.com/zim-desktop-wiki/zim-desktop-wiki/issues