unlike twiki release prior to dakar 4.0.1:

• versioning of attachments broken:
  • using "upload" within "manage" function does not change the attached file content and increments the version ID of the current attachment, but instead creates a new attachment - leaving the existing attachment unchanged
  • the version for attachments so never increases above "1"
  • changing file content of one attachment now always requires to delete the previous file

this represents a major loss to the previuos twiki release.

user acceptance is decreasing in our organization therefore.

---

I have tried to reproduce this on the TWiki4 test server

I can upload a file 2nd time through manage and I get a new name each time.

Can you try and explain more what you do?

What filename do you use?

KJL

I'm having problems reproducing any of this as well, unfortunately.

What platform are you on? This might sound a bit in line with problems on Windows installations reported earlier (RCS problems).

Dirk, it would be helpful if you would try to reproduce this in the TWiki VM (TWiki:Codev.TWikiVMDebianStable), preferable with very detailed step-by-step instructions on how you provoke the error.

Glad to hear you're trying to solve the issue before acceptence decreases too much - can't have that!

-- SP

Cannot reproduce; no feedback from reporter; discard.

CC

--

Sorry Crawford i didn't respond in time. I was absent and couldn't check the bug status and comments.

However, I'm not using a Windows plattform but: Apache/2.0.53 (Linux/SUSE)

To reproduce the issue, this are the steps taken:

1. attach file "test1.txt" with content "test 1" to item TestItem
2. change content of local file "test1.txt" on harddrive to "test 2" and save file
3. click on "manage" for file "test1.txt"
4. browse file "test1.txt" (again)
5. upload (changed) file "test1.txt" (again)
6. click on "manage" for file "test1.txt"
7. issue: version counter for file didn't increase, table showing versions of attachment didn't get an additional line
8. however: "test1.txt" indeed has "test 2" as content - as supposed to be, but older version(s) are completely lost and no version history is recorded

This is a common use case for a group ware tool as Twiki is positioned to be. Multiple collaborators working on same file, changing or adding content. Older versions should be retrieveable and change activity on attachments should be tracked - as it was on Cairo release if I remember right...

Thank you for following up on this again.

Dirk

---

I have tested this again. And it works as it should.

There is either something wrong with your setup, or you have an older buggy version of TWiki 4.

When I wanted to reproduce this a few minutes ago my reaction was "He is right". But then I noticed that I had accidently clicked "Change Comment and Properties Only" instead of "Upload File". Maybe this is what you are doing too?

In any case. Running with the code that gets released as 4.0.2 in a few days I cannot reproduce the problem. See here.

http://merlin.lavrsen.dk/twiki/bin/view/Sandbox/SomeTopic4You

KJL

The only way I can think of to do something that vaguely resembles the usecase and produces a "similar error" is to have test1.txt contain "test 2" at first upload. In this case no new version is produced, which is according to spec.

Discarding this, pending a reproducible report. If at all possible could you reproduce it in TWiki:Codev.TWikiVMDebianStable (reproducible environment)?

-- SP

http://twiki.org/cgi-bin/view/Sandbox/RandomTestTopic1807

1. Created topic
2. Attached file test1.0.txt
3. Clicked manage link of test1.0.txt
4. Choose file test1.1.txt
5. Comment 1.1
6. Selected Hide Attachment
7. Upload

A new file is created instead.

I find suspicious code here: lib/TWiki/UI/Upload.pm line 182:

        # cut path from filepath name (Windows '\' and Unix "/" format)
        my @pathz = ( split( /\\/, $filePath ) );
        my $filetemp = $pathz[$#pathz];
        my @pathza = ( split( '/', $filetemp ) );
        $fileName = $pathza[$#pathza];
        $origName = $fileName;

It unconditionally changes the attachment name to the uploaded filename.

This overrides the previous code line 157:

    if ( $filePath && ! $fileName ) {
        $filePath =~ m|([^/\\]*$)|;
        $fileName = $1;
    }

This breaks upload a new file with DIFFERENT name for same attachment. Local filesystem does not support versioning so filenames are often modified to include version information. This is incompatible with TWiki upload via manage.

Perhaps this is an attempt to avoid confusion caused by uploading a file and having it change names (perhaps even extensions). Here's my proposed fix from 4.0.2 (sorry I haven't upgraded yet):

diff -r1.1.1.2 Upload.pm
155a156,160
>     my $origName = '';
>     if( $filePath ) {
>         $filePath =~ m|([^/\\]*$)|;
>         $origName = $1;
>     }
158,159c163
<         $filePath =~ m|([^/\\]*$)|;
<         $fileName = $1;
---
>         $fileName = $origName;
179d182
<     my $origName = $fileName;
182,188d184
<         # cut path from filepath name (Windows '\' and Unix "/" format)
<         my @pathz = ( split( /\\/, $filePath ) );
<         my $filetemp = $pathz[$#pathz];
<         my @pathza = ( split( '/', $filetemp ) );
<         $fileName = $pathza[$#pathza];
<         $origName = $fileName;
< 
251c243
<     if( $fileName eq $origName ) {
---
>     if( $doPropsOnly || $fileName eq $origName ) {

This allows upload of file with new name for the old attachment but generated the renaming warning.

-- TWiki:Main.JadeCravy

I cannot remember it was has ever been the spec that TWiki could rename an attachment when it was uploaded except when it does it by itself to protect against executable items.

I am not even sure I would want it too.

I prefer that if I upload a file it is created with the same name no matter if I do it with Manage or with straight attach.

For sure this cannot be a requirements. I have changed it to Enhancement and will let other developers give their oppinion whether to implement or discard.

-- KJL

I just tested this on Cairo. It behaves the same way as TWiki4. Nothing has changed. You could not via manage upload a different filename without also creating a new attachment with this filename.

I recommend discarding.

-- KJL

This description on the manage page is contrary to that interpretation: "Select a new local file to update attachment CustomLogic_open_items_list.xls (JadeCravy)"

There is currently a note in the expandable help text that contradicts this (that is describes the actual behaviour).

TWiki:Codev.UpdateAttachmentsDontWorkAsExpected

TWiki:Codev.AttachmentLogicFlawed

If you intend to maintain the current implementation, then the template text needs to be corrected.

Perhaps move the file upload out of that form entirely and add a note to the general attach description: "Attach a local file with the same name as an existing attachment to add an additional version."

If the upload is maintained, but doesn't work as expected an error page should be shown: "Attached file did not match managed attachment; a new attachment was created instead."

But like I mentioned above, it is desirable to convert the filename when going from a unversioned OS to a versioned storage system. If you choose not to change it, add this as an enhancement request.

Also note, Mac OS used to use ":" as path separator, this is not handled here.

---

Changing to No Action. Just tested on 1.2.0

• uploaded test1.txt (file containing "test1")
• Attachment was saved as test1.txt
• Selected manage test1.txt, and uploaded test2.txt (file contained two lines - test1 and test2)
• only a single file is listed in the attachments list - test1.txt
• Selected manage test1.txt, 2 revisions were shown, and contain the expected contents.