I noticed that bundled directories of an application are not updated when the application’s they belong to is updated.
For example, I have an application A version 1.0.0 with the following adef file:
version: v1.0.0
sandboxed:false
executables:
{
myExec = ( MyComponent )
}
processes:
{
run:
{
( myExec )
}
}
bundles:
{
dir:
{
[rw] data ./
}
}
the data directory contains one file named “myFile.txt”
If I change the content of myFile.txt and if I bundle it into a new version of my application (v1.0.1 for example) after having update the application onto the target, the content of myFile.txt is not updated. The old content still present into the file system.
I observed this behaviour for both local and remote update (through AirVantage).
How can I force the system to override myFile.txt with the one of my new application ?
This looks like a bug in how updates are handled – the upgrader will not overwrite existing bundled files with a new file with the same name. As far as I can tell the only way (currently) to force the system to install the new file is to give it a different name.
I’ve entered an issue for this in our bug tracker.
am also interested if this has been solved. By the way - can anyone send me a link to the mentioned Jira site for bug tracking please? Am not able to find it anywhere…
unfortunately is neither removing the app in before for us an option nor a file renaming.
By the way - I did some investigation and could see that actually the updated bundled files are transferred to the target, but not within the app’s folder. This is what I could see:
I got a bundled file: blah.sh which shall be updated. After update I can see 2 different locations of this file:
/legato/systems/current/appsWriteable/dirtest/bin/blah.sh
and
/legato/systems/current/apps/dirtest/writeable/bin/blah.sh
The last file location contains the updated content, but when starting the app (which shall give out the content), it only issues the old one (seen on 1st file location).
Does somebody know about this behavior? Are there any ways to influence this maybe?
This seems to be the intended behaviour of the bundling mechanism with rw files. The reason why the file is not updated is because the file might have been updated by the user already and replacing it will result in loss of all the data.
I was also thinking about this possible intention - but shouldn’t this process better be configurable? Because it may also be the case that a file must be overwritten by an update - ignoring any user changes on it…
To do the override, user can upgrade their application and modify the bundled file as ro. This will override the existing file as ro. If they really want it to rw again, they will need to upgrade again but specify their bundle file as rw.
unsandboxed app is not an option sadly. I was already trying to modify file attributes (rw<->r), but this is not permitted. Maybe this has something to do with the smack rules.
how about updating the app twice?
the first time will be using RO, then the file on the module will be updated.
The second time will be using RW, then you can modify the file.
yeah - during a common system update it is permitted to overwrite a read-only file. Hence the only solution I see would be to rename all bundled rw-files first, the do the update and in case of success such renamed files could be deleted or moved back (when update fails).
