Defect #622

"File" stereotype :deletion of file, problem of relpicated MD

Added by Blatti Yves over 5 years ago. Updated over 2 years ago.

Status:AffectedStart date:07/15/2013
Priority:HighDue date:
Assignee:Battaglia Marc% Done:

0%

Category:CATALOG
Target version:Unplanned
Affected version:4.0.0

Description

Problem with "File" stereotype:
If we replicate a metadata with an existing linked file, then the replicated metadata can delete the file of the original.

This is not an important issue for us (we can disable the deletion on file), but we must not reproduce it in V4.


Related issues

Related to easySDI - Enhancement #801: Extend file/upload stereotype to allow external URL Closed

History

#1 Updated by Mérour Xavier over 4 years ago

  • Assignee set to Magoni Bruno

What about this issue in V4 Bruno ?
Do you have any input on the way the stereotype in v4 was coded ?

#2 Updated by Magoni Bruno over 4 years ago

  • Project changed from CATALOG to easySDI

#3 Updated by Magoni Bruno over 4 years ago

  • Category set to CATALOG

#4 Updated by Magoni Bruno over 4 years ago

  • Target version set to Unplanned
  • Affected version changed from 2.4.2 to 4.0.0

#5 Updated by Magoni Bruno over 4 years ago

  • Assignee deleted (Magoni Bruno)

Hi Yves,

Is it possible for you to verify that such problem always exists in V4?

Thanks a lot for your help!
Bruno

#6 Updated by Magoni Bruno over 4 years ago

  • Priority changed from Low to Normal

#7 Updated by Blatti Yves over 4 years ago

Just tested, and the problem is still present on V4.0.1

#8 Updated by Blatti Yves over 4 years ago

I see multiple ways of fixing it (and there's certainly many other, we'll have to discuss them)

1. "The XML way" : on replication, parse XML for "locally attached items", if found, duplicate the files with a new name, and replace the links.

2. "The Filesystem way" : we choose to name attachment with MD identifiers (prefix), or place them in an identified folder (let's say .../media/easysdi/images/md_guid/uniquefilename.ext), when we replicate a metadata, we replicate all the files with the prefix OR the whole folder related to the metadata.

3. "The dirty way" : on deletion of an attachment (of a replicated metadata), we don't delete the file, it stays on the system, so the "original" metadata keeps pointing on it

Let's compare them:

Method Ease of implementation "Beauty" Migration/Update problem remark
1. "The XML way" -- ++ no problem with existing data Looks a bit heavy to solve a small problem...
2. "The Filesystem way" + + we'd have to parse all existing MD and rename or move attachments Looks like a good compromise but, the update is a problem
3. "The dirty way" ++ -- no problem with existing data
(but problems in the future... with orphaned files...)
could be used temporarily, waiting for a clean fix

Other (better) solutions/proposals welcome ! ;-)

#9 Updated by Magoni Bruno over 4 years ago

  • Target version deleted (Unplanned)

#10 Updated by Magoni Bruno about 4 years ago

  • Assignee set to Technical Committee

#11 Updated by Magoni Bruno almost 4 years ago

  • Status changed from New to Affected
  • Assignee changed from Technical Committee to Blatti Yves

3rd option will be temporarily followed, waiting for a complete fix...

#12 Updated by Mérour Xavier over 3 years ago

  • Priority changed from Normal to High

#13 Updated by Magoni Bruno over 3 years ago

  • Target version set to Unplanned

#14 Updated by Magoni Bruno over 3 years ago

  • Target version deleted (Unplanned)

#15 Updated by Magoni Bruno over 3 years ago

  • Related to Enhancement #801: Extend file/upload stereotype to allow external URL added

#16 Updated by Magoni Bruno over 3 years ago

  • Assignee changed from Blatti Yves to Magoni Bruno

As validated in #801, method 1 will be used to fix such issue (note 11 is not up to date anymore).

#17 Updated by Magoni Bruno over 3 years ago

  • Target version set to 174

#18 Updated by Magoni Bruno over 3 years ago

  • Target version changed from 174 to Unplanned

#19 Updated by Magoni Bruno over 3 years ago

  • Assignee deleted (Magoni Bruno)

For now the temporary "dirty way" will be covered until Community works on the "XML way"...

#20 Updated by Blatti Yves about 3 years ago

  • Assignee set to Technical Committee

Can it be closed now ? -> #801

#21 Updated by Van Hoecke Hélène about 3 years ago

  • Assignee changed from Technical Committee to Battaglia Marc

Can you answer Marc?

#22 Updated by Mérour Xavier over 2 years ago

Hello Marc,

We (Yves and I) are doing our cleaning session in the forge.
Can you give us some inputs on this one (i.e. can we close it ?)

Thanks

#23 Updated by Mérour Xavier over 2 years ago

Marc,

Any news on this issue please ?

Thanks

Also available in: Atom PDF