Some Eclipse Foundation services are deprecated, or will be soon. Please ensure you've read this important communication.

Bug 220647

Summary:

[native] Support for file manipulation actions

Product:

[Eclipse Project] Equinox

Reporter:

Simon Kaegi <simon_kaegi>

Component:

Assignee:

P2 Inbox <equinox.p2-inbox>

Status:

RESOLVED DUPLICATE

QA Contact:

Severity:

normal

Priority:

CC:

henrik.lindberg, pascal, thomas

Version:

3.4

Keywords:

helpwanted

Target Milestone:

3.5

Hardware:

OS:

Windows XP

Whiteboard:

Attachments:

Description	Flags
CopyAction and CleanupcopyAction for o.e.e.p2.touchpoint.natives	none
JUnit tests for CopyAction - o.e.e.p2.tests project	none
Take 2 - CopyAction and CleanupcopyAction for o.e.e.p2.touchpoint.natives	none

Description Simon Kaegi

2008-02-27 14:43:32 EST

We currently have a few file manipulation actions in the native touchpoint that are likely to be useful during configuration of IUs with more specific touchpoint types. We should consider having a set of basic file manipulation actions available to all touchpoints. What I have in mind are:

cp
rm
mkdir
rmdir
mv (probably although I don't have a current use-case)

These are in addition to the native touchpoints:
zip
cleanzip (open to a better name here)
chmod

Comment 1 Pascal Rapicault

2008-02-27 20:13:43 EST

we would likely need an ln as well

Comment 2 Henrik Lindberg

2009-01-23 19:55:14 EST

I badly need the cp action in a use case, and have written a CopyAction and a CleanupcopyAction together with test cases. Expect to supply patches shortly.

The implementation is similar to the zip actions as both files and directories are handled.

I don't see as much need for a Remove, but a MoveAction (with corresponding CleanupMove) is quite useful in cases where an existing file needs to be backed up (some systems are poorly designed and requires that users modify some configuration file - being able to move it is a good thing).

If a Remove is implemented - any ideas about how to handle "undo"? Should removed files be kept around  forever, or can they safely be removed at some defined end of the operation?

Looking at the implemented actions (unzip and link) - none of them are really capable of putting back overwritten files - only removing what they wrote. Is there some other mechanism to restore overwritten files?

Comment 3 Henrik Lindberg

2009-01-23 20:15:32 EST

Created attachment 123614 [details]
CopyAction and CleanupcopyAction for o.e.e.p2.touchpoint.natives

Comment 4 Henrik Lindberg

2009-01-23 20:21:45 EST

Created attachment 123617 [details]
JUnit tests for CopyAction - o.e.e.p2.tests project

Comment 5 Henrik Lindberg

2009-01-23 20:33:43 EST

Created attachment 123618 [details]
Take 2 - CopyAction and CleanupcopyAction for o.e.e.p2.touchpoint.natives

Forgot support for @artifact as source in copy. New patch has that as well.

Comment 6 Henrik Lindberg

2009-01-29 16:40:51 EST

The CopyAction and CleanupCopy actions are included in the larger patch attached to  bug 262333 which also contains an implementation of the BackupStore.

Comment 7 Henrik Lindberg

2009-01-29 17:40:10 EST

A RemoveAction is now included in the patch to bug 262333.

Of the listed actions in this issue, only "mv" remains - which naturally could be done with a copy and a remove.

Comment 8 Pascal Rapicault

2009-02-20 10:28:47 EST

Henrik, are the tests attached here also attached to bug 262333? If so I propose, please close this bug as a dupe of it.

Comment 9 Henrik Lindberg

2009-02-20 16:53:51 EST

Attachements in this issue are also in bug 262333 - implementatino and tests. The new actions added there covers the proposed actions in this bug,

*** This bug has been marked as a duplicate of bug 262333 ***