currently i don't see the possibility to copy links with the copy command. is this correct? will this be added? (the content of links can be copied but not the links itself)
However, I've just tested and you are absolutely right.
FOLLOWLINKS does nothing - the copy command even spews out "links are not copied" text next to any links, as if FOLLOWLINKS hadn't been specified. COPYLINKS copies the file pointed to by the link, rather than the link itself.
@MichaelMerkel I've had to use WorkBench drag-n-drop for system backups for ages. Hyperion's installers create links in the OS4 SDK and in SYS:SObjs but you can't back them up "with links" unless you do it with drag-n-drop. I just tested the "copy" command on several links to confirm the problem and discovered another problem. The copy command doesn't copy the protection bits from the original file either. I created a soft link to a script and the "S" protection bit was not copied to the file that was created. That means that script links that are copied in a system backup with the "copy" command will not work when the system is restored.
Speaking of protection bits; I notice that some of the files in SYS:Sobjs have the execution bit set and others don't. Also, some of the Python scripts have the script bit set and others don't. Since I don't know anything about Python, that may be intentional. In the SDK some link libraries have the execution bit set which shouldn't be the case. Overall, they seem like sloppy installations when it comes to setting correct protection bits.
xenic wrote: ... The copy command doesn't copy the protection bits from the original file either. I created a soft link to a script and the "S" protection bit was not copied to the file that was created. That means that script links that are copied in a system backup with the "copy" command will not work when the system is restored.
using the CLONE attribute *should* copy all protection bits.
Speaking of protection bits; I notice that some of the files in SYS:Sobjs have the execution bit set and others don't. Also, some of the Python scripts have the script bit set and others don't. Since I don't know anything about Python, that may be intentional. In the SDK some link libraries have the execution bit set which shouldn't be the case. Overall, they seem like sloppy installations when it comes to setting correct protection bits
Execute is set by default on anything GCC creates. It probably shouldn't be set on SObjs and certainly not on static ones - most plain text files get it too. It used to annoy me in the old days when text files without a real icon also didn't have Execute set - with Execute set double-clicking would open the Execute file window where you could add "ed" (or multiview, or whatever) to the start and click OK. I rather liked that system prior to DefIcons - but plain text files really shouldn't be set as executable.
Python scripts probably should be set as Script and Execute. Certainly with ARexx if these are set, you can directly run the script in the Shell. I assume the same support has been added for Python although having never used it, I have no idea if this is the case.
Python scripts probably should be set as Script and Execute. Certainly with ARexx if these are set, you can directly run the script in the Shell. I assume the same support has been added for Python although having never used it, I have no idea if this is the case.
Python scripts are supported the same as ARexx scripts are. You can execute them directly if the script bit is set. The same goes for .pyc files for even more speed.
Last time something broke my SDK I tried to copy it back from the backup with WB but it was still broken afterwards. Then I copied it with YetAnotherDesk and SDK started to work fine again. Currently YetAnotherDesk copies all files first and copies/creates links last making sure the target file exists when it tries to copy/create the link. I guess WB/AsyncWB copies everything in that order it reads them from the disk (so it might read the link before the actual target file).
Rock lobster bit me - so I'm here forever X1000 + AmigaOS 4.1 FE "Anyone can build a fast CPU. The trick is to build a fast system." - Seymour Cray
using the CLONE attribute *should* copy all protection bits.
Yes. I tested "copy CLONE" on a soft link and it did copy the protection bits. However, copy (without CLONE) on a real file copies the protection bits so at the very least there is an inconsistancy. Copy CLONE is necessary to copy the protection bits for a soft link but not necessary to copy the protection bits for a real file.
Last time something broke my SDK I tried to copy it back from the backup with WB but it was still broken afterwards. Then I copied it with YetAnotherDesk and SDK started to work fine again. Currently YetAnotherDesk copies all files first and copies/creates links last making sure the target file exists when it tries to copy/create the link. I guess WB/AsyncWB copies everything in that order it reads them from the disk (so it might read the link before the actual target file).
I don't think the order matters for soft links. AsyncWB will copy a link to a file that doesn't exist but list the size as -1. Hard links must point to a valid file so in that case copy order matters. Another problem is that some filesystems don't handle links at all (especially hard links) or treat them differently.