Done, logged issues 262333-262337, and I am almost done with a BackupStore implementation.
On Jan 25, 2009, at 3:56 AM, Simon Kaegi wrote: 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 wrote: 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
p2-dev mailing list
p2-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/p2-dev
|
