Re: [p2-dev] Issues with Native Touchpoint Actions

[Simon Kaegi <Simon_Kaegi@xxxxxxxxxx>]

re: If I understand it correctly, the native touchpoint is involved in the  
transaction management, and could potentially be responsible for  
putting back removed files on a rollback operation.

Should I open one or several issues for these? Seems to fit the theme  
of "Robustness" for 3.5 ;)
--
That would be great! Transaction file actions are an essential building block IMO.

Henrik Lindberg ---01/24/2009 09:28:23 PM---Hi,

From:	Henrik Lindberg <henrik.lindberg@xxxxxxxxxxxxxx>
To:	P2 developer discussions <p2-dev@xxxxxxxxxxx>
Date:	01/24/2009 09:28 PM
Subject:	[p2-dev] Issues with Native Touchpoint Actions

---

Hi,
I have been looking at the Native Touchpoint actions - primarily to  
see how they deal with backup / rollback, as I wanted to do it right  
in the CopyAction that I have implemented. And I found several  
surprising things....

LinkAction:
- How is the link action supposed to work on windows? It performs  
Runtime.exec("ln -s....."). And as far as I understand there is no  
"ln" command on a windows box. Although linking is possible on NTFS  
filesystems I don't think symbolic linking is supported across  
different Windows versions - some support symbolic linking to folders  
only.
- Is LinkAction only supposed to be used on environments that support  
a "ln -s" command?
- The link command completely ignores errors - it just swallows  
IOExceptions.
- Subsequently, the LinkActionTest executes a link operation, and  
expects an exception if something is wrong - it never checks that the  
link actually suceeded. Thus, this test will report false positives.

UnzipAction:
- The UnzipAction uses FileUtils.unzipFile, which ends up in  
FileUtils.unzipStream - in this code, if a file being unzipped already  
exists, it is removed before copied over. The undo of an unzip runs  
Cleanupzip action and removes the files that were unzipped. There is  
no backup of overwritten files. Is this intentional?

CleanupzipAction:
- Is used both as an undo of unzip, and as an instruction on its own.
- It removes files and (non empty) directories that were previously  
unzipped.
- An undo of cleanupzip performs a new unzip. If I understand this  
correctly this means that the zip file artifact in the artifact  
repository must still be around - if it is not, then the installation  
will be corrupted.

Mkdir:
- Mkdir tries to create a directory with the supplied path, and always  
returns ok. There is no check if the file already exists (and is not a  
directory). Is this intentional?
- If an undo is performed - the code simply removes the path.
- This leads to that a mistake in the mkdir instruction can cause  
delete of a file if the provisioning action rolls back.

Rmdir:
- Rmdir simply removes the path it is given - irrespective of if it is  
a file or a directory.
- On undo, it creates a directory
- A mistake in the install instruction can thus lead to the  
replacement of a file with content with an empty directory

If I understand it correctly, the native touchpoint is involved in the  
transaction management, and could potentially be responsible for  
putting back removed files on a rollback operation.

Should I open one or several issues for these? Seems to fit the theme  
of "Robustness" for 3.5 ;)

Henrik Lindberg
henrik.lindberg@xxxxxxxxxxxxxx

_______________________________________________
p2-dev mailing list
p2-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/p2-dev