Item1735: Copying a topic with attachments results in broken attachment links

Priority: Normal
Current State: Closed
Released In: 1.1.0
Target Release: minor
Applies To: Engine
Reported By: PhilippLeufke
Waiting For:
Last Change By: KennethLavrsen


When creating a copy of a topic which contains attachments, the files aren't copied as well. This results in an inconsistent behaviour: since the META tags get copied, the list of attachments features all of them, but as the files from the PUBDIR are not copied, all links are broken.

Deleting the attachments (i.e. deleting the META tag) will not work as well, since the file cannot be found.

Possible solutions

Several solutions seem to be more or less reasonable:
  • Automatically copy the attached files as well (I guess, a user would expect this)
  • Ask the user whether the files should be copied and if not, remove their META tags (most flexible and convenient solution)
  • Only create links (HTML or symlinks) to the original files (maybe too confusing)
  • Do not copy attachments and remove their META tags instead (may not be the expected behaviour)

In all cases it may make sense to scan the topic for links to attached files before copying and
  • tell the user about this, and/or
  • update the links to make them point to the original topic or to the copy, if the attachments were copied as well

This seems to be a duplicate of Item2185 and Item1979. Also, I can confirm that this hasn't been fixed as of Foswiki 1.0.9.

-- BryanThrall - 31 Mar 2010

When creating a new topic as a copy of a previous one, using the templatetopic parameter to edit, and the original topic did have attachments, then the newly created topic will contain metadata referring to those attachments but not the attachments themself. So the list of attachments will mention them, but they still won't be available.

-- MartinVonGagern - 26 Aug 2009

It is probably not such a problem that attachments are not being copied, but because the metadata is, it looks like the attachments have been copied. But the links are dead.

Proposed solution: remove attachment metadata from the copied topic

-- ArthurClemens - 29 Sep 2009

I would prefer attachments actually copied also - or an option to clone with or without

Otherwise cloning topics with graphics is a pain

-- KennethLavrsen - 29 Sep 2009

Me too. Confirmed.

-- CrawfordCurrie - 15 Dec 2009

Once implemented a CopyContrib that allows to copy a topic or parts of it. Not published yet. Doesn't deal with strikeone yet.

-- MichaelDaum - 15 Dec 2009

Voting for this. Agree that it should copy the whole thing as-is, attachments included, as a minimum. Should probably offer not to copy attachments, but default should be to copy them. (Bonus points for choosing which ones to copy and which to exclude, but this is getting fussy.)

-- MarcusLeonard - 16 Jun 2010

I had a go at fixing this, and actually had a fix for 1.0.x, but the store code has changed in 1.1 and I haven't been able to complete it.

I have checked in my unit test, but commented it out for now so it wont be sent out as a failure. Please feel free to take this on.

Unless this gets fixed for 1.1, we should at least stop the attachments META data being copied over and prevent the broken links. The copy page already states that attachments are not copied over.

-- AndrewJones - 19 Jul 2010

I added Foswiki::Meta::copyAttachment for you. Use that.

-- CrawfordCurrie - 19 Jul 2010

Done for 1.1.

-- AndrewJones - 19 Jul 2010

Updated the (now incorrect) message in the more template, and added releasenotes.

-- CrawfordCurrie - 20 Jul 2010

Sorry I should have done that as well. Bad form.

-- AndrewJones - 20 Jul 2010

ItemTemplate edit

Summary Copying a topic with attachments results in broken attachment links
ReportedBy PhilippLeufke
Codebase 1.0.9
SVN Range Foswiki-1.0.0, Thu, 08 Jan 2009, build 1878
AppliesTo Engine
Priority Normal
CurrentState Closed
Checkins distro:6ca4d13c58e5 distro:cc8267ca2836 distro:5c3cd6fe1f46 distro:b24330457cd4
TargetRelease minor
ReleasedIn 1.1.0
Topic revision: r15 - 04 Oct 2010, KennethLavrsen
The copyright of the content on this website is held by the contributing authors, except where stated elsewhere. See Copyright Statement. Creative Commons License    Legal Imprint    Privacy Policy