Another Duplicate File Issue: Stuck in the middle with you.

[kcondon]

See RT 295094, Julian mentioned some intermittent issue uploading files where it failed with the dupe files message:

The first time I tried to upload both files at the same time by dragging them both into the window, after the progress bar for both files filled up, I got an error message about a duplicate file name "0V". I thought it would happen again and planned to take a screenshot then, but it didn't happen when I tried uploading the files a second time.

When I hit cancel and tried the second time, I dragged one file in first, waited for it to load, which took a few seconds, and dragged the second file in. And I didn't get an error for either file. So I tried dragging both files in so I could copy the duplicate file name error, but both files uploaded successfully.

I hit cancel again and asked the depositor to try uploading both files again.

There are 68 files with the file name "0V".

The dataset, doi:10.7910/DVN/OJHYZA has 68 duplicate files named 0V. This likely occurred through a loop hole in an earlier version of Dataverse, maybe 5.0.

There are also 2 duplicate files named 0.5V. There may be others. Not sure whether fixing them entails only renaming them in a new draft or in the existing published version since it is an illegal state and may cause other issues at a later date.

The reason this became an issue is that you cannot upload or save any changes to files until these dupes are fixed.

1. Upload 2 new files, save, fails with error: × The files could not be updated. – Duplicate filenames: 0V
2. Rename all 68 0V files in UI, save, fails with error: × The files could not be updated. – Duplicate filenames: 0.5V

[landreev]

This likely occurred through a loop hole in an earlier version of Dataverse, maybe 5.0.

No, definitely before v5 - I remember that dataset, it had other issues. :)

[landreev]

The fact that you can't even upload new files if there are duplicate filenames is pretty insane.
And as for fixing any existing dupe filenames - it just sounds like they need to be fixed all at once...

[landreev]

(I'll handle fixing it in the specific dataset above; let's use this issue for any code fixes)

[landreev]

Hmm, I haven't been able to reproduce it just yet. I created a dataset, and created a few duplicates (in the db directly). And so far I can both upload, and change 2 dupe filenames at a time...
Do I need a published version maybe? (the dataset above does)

[landreev]

I don't know what's going on. I was able to reproduce the above condition when I published my test dataset, and then (immedately) tried to upload another file. Then it failed to save with a dupe message, complaining about an existing duplicate. But once I have created a draft, by making a metadata change, I am back to being able to make any changes I want.

Uh, including being able to create new duplicates. Something is still seriously buggy there.
I'll let somebody else try to figure out what's going on.

[landreev]

Last note: With the dataset above, it WAS possible to fix all the dupes in the UI; without having to mess with direct database updates. They just had to be changed all at once. Trying to change just some was resulting in an error.
IDK - is this a bug, or is this how it was supposed to be implemented? - I'll leave it to those who worked on on this functionality recently.

[landreev]

I'm still curious as to why I can't reproduce this on my own dev. box; what's so different between my dataset and the one above?
edit: It's not just that I can't reproduce the above; for me the duplicate name check is just no longer being enforced at all, once I have an existing draft version. Hmm?

[pdurbin]

@landreev this might help you reproduce the issue:

• Failed to Publish Dataset – The dataset could not be published because one or more of the datafiles in the dataset could not be validated (physical file missing, checksum mismatch, etc.) Please contact support for further assistance. dataverse-sample-data#32

Or maybe what I found is a different issue? I'm not sure.