Code:
<characteristic type="FileOperation">
<characteristic type="%CE2%\Start Menu\Programs\Games" translation="install">
<characteristic type="MakeDir" />
<characteristic type="Pocket Uno.lnk" translation="install">
<characteristic type="Copy">
<parm name="Source" value="%CE2%\Start Menu\Programs\Pocket Uno.lnk" translation="install" />
</characteristic>
</characteristic>
</characteristic>
<characteristic type="%CE2%\Start Menu\Programs\Pocket Uno.lnk" translation="install">
<characteristic type="Delete">
<parm name="ForceDelete"/>
</characteristic>
</characteristic>
</characteristic>
I too tried this and it didn't work (was trying to move the "Bing.lnk" that's marked read-only and system). After cabbing it up separate "copy" and "delete" fileops and running I get "unsuccessful". (I built the xml on a working "move" xml file)
I think it's because the definition of "ForceDelete" doesn't appear to have anything to do with attributes (it sounds more like a lock override if another program has the file open for editing):
msdn.microsoft.com/en-us/library/bb737563.aspx said:
ForceDelete
This parameter can be used in the Delete characteristic to delete the file even if the shared reference count is not zero.
I also tried using this parameter with a move:
msdn.microsoft.com/en-us/library/bb737563.aspx said:
RemoveAttributes
This parameter can be used in a Copy or Move characteristics to remove the Archive (A), Hidden (H), ReadOnly (R), or System (S) attributes on the destination file. Requires the Manager role.
But got the same error (perhaps I screwed up the code...):
Code:
<wap-provisioningdoc>
<characteristic type="FileOperation">
<characteristic type="%CE17%\Programs\GPS" translation="install">
<characteristic type="MakeDir" />
<characteristic type="Bing.lnk" translation="install">
<characteristic type="Move">
<parm name="Source" value="%CE17%\Programs\Internet\Bing.lnk" translation="install" />
<parm name="RemoveAttributes" />
</characteristic>
</characteristic>
</characteristic>
</characteristic>
</wap-provisioningdoc>
This is just spitballing, but maybe we don't have the "Manager Role" when installing from a CAB? I'll try running directly from SDAutoConfig later.
I like the clean Mortscript example, but that only works if Mortscript is installed. I don't want to bank on that if I don't have to (i.e. stock roms, etc).
Also, I tried testing these fileops xml files (even working ones) with SASHIMI, but it doesn't seem to do anything (no errors, nothing)??? Am I missing something??? (I think it would be easier to test with SASHIMI rather than cabbing with SDConfig Builder each time).
Any ideas on the code or the testing?
FYI - currently I'm running Energy.HERMAN.23529.Sense.2.5_MaxManila.16.Feb.2010.rar (and yes, it has mortscript installed, and I know SASHIMI installs it too - I'm in the alpha phase of my re-install script here ---> just testing everything

)