Not that I guess anyone is interested but I did finally use my (seemingly correct) new understanding of GetDeviceProc()/etc to rewrite my broken code... and tests seem to show they do actually work! (Also they achieve what I originally set-out to do, which was get the correct result for a soft link that is not at the top of a multi-assignment.)
FWIW, I found some code showing how to test whether a link (from a previously successful ReadLink()) is a soft or hard, using some DoPkt3() magic. Should be much more efficient that using ExAll()...
OK, thanks to "MultiAssign.txt" & "multilist.c" (from Amiga Mail Vol 2), I think that I finally understood what is happening, although I'm still not 100% sure:
I was confused by the docs too. I ended up writing a short test program with losts of printf() calls to figure out how it works.
Amiga X1000 with 2GB memory & OS 4.1FE + Radeon HD 5450
FWIW, I found some code showing how to test whether a link (from a previously successful ReadLink()) is a soft or hard, using some DoPkt3() magic. Should be much more efficient that using ExAll()...
I'll show E code, since I can't be bothered to manually translate it into C, but it should be pretty close anyway.
After a successful "devProc := GetDeviceProc(path, devProc)", which was used with "len := ReadLink(devProc.port, devProc.lock, pathNoVolume, buf, bufSize)", you need to convert "path" into a bcpl string, then you can call "lock := DoPkt3(devProc.port, ACTION_LOCATE_OBJECT, devProc.lock, bcplPath, SHARED_LOCK) !!BPTR". If you obtain a lock, then it must be a hard link, otherwise it is probably a soft link. In theory you can use "IoErr() = ERROR_IS_SOFT_LINK" to check if it is a soft link, but in some situations I got at least one other error messages for soft links (ERROR_OBJECT_NOT_FOUND), and I suspect such error messages vary between different filingsystem implementations so I decided to always assuming it is a soft link.
Unfortunately I haven't test if this works on hard links, as I think only FFS supports hard links.
@Raziel, nbache Chances of me adding to the wiki (at the moment) are probably zero, sorry. (I'm behind on too much other stuff already, without trying to do more things.) But I certainly wouldn't mind someone else taking what I posted, and adding it.
>That'll be because the SDK is 2-3 years out of date. The little pop-up menu you can have in window borders isn't available to any devs either for the same reason. I'm sure there must be other things that have been added but we have no access to.
I agree, I even asked specifically for those tag values and was told it wasn't important, apparently. If it is so unimportant that no one should bother using it then why was it added to the OS in the first place?
H&P and Commodore before them were always much more professional and had a higher standard of developer support.
I had a similar problem when the 32-bit icons were introduced - ended up getting the values from the author of afaOS' icon.library (I have no idea how he got hold of them).
I thought communication had improved significantly since then, perhaps not.
I'm not part of that decision process but would guess that the logic there is that it;s a minor feature, not worth releasing beta documentation for, (with attendent risks and confusion that might cause).
After all it's not the end of the world if a port of a 68k app that doesn't have drop down menus in the title bar doesn't have drop down menus in the title bar either. Nice as they would be.
I'm not part of that decision process but would guess that the logic there is that it;s a minor feature, not worth releasing beta documentation for, (with attendent risks and confusion that might cause).
After all it's not the end of the world if a port of a 68k app that doesn't have drop down menus in the title bar doesn't have drop down menus in the title bar either. Nice as they would be.
That would be my thinking too. If it was a matter of the program not being able to work at all without the new SDK feature then some kind of exception should be made but for something as simple as this it may as well wait for a proper SDK release which hopefully should happen soon.
FWIW, I found some code showing how to test whether a link (from a previously successful ReadLink()) is a soft or hard, using some DoPkt3() magic. Should be much more efficient that using ExAll()...
For OS4 there really isn't a need to distinguish between hard and soft links. Links are automatically resolved by AmigaDOS when read and creating hard links is pointless now that soft links work. Besides, if you are creating a hard link, you would need to be sure the filesystem is FFS. I think hard link creation should just be removed from OS4 AmigaDOS and the Makelink C command. Hard links are just an added programming complication and serve no useful purpose.
Amiga X1000 with 2GB memory & OS 4.1FE + Radeon HD 5450
If you are e.g. a backup program in the process of replicating a directory tree containing links, it does matter to you, as you would want to create the same kind of link on the destination (if possible).
As nbache said, if *does* matter if one is intending to backup links! As both my AmigaAttributes & AmiSystemRestore programs need to do
Since most people are using SFS or JXFileSystem, you can't reproduce hard links on those filesystems anyway. For a backup, you can replace a hard link with a soft link and it will work exactly the same when you restore your backup.
@nbache Quote:
If you are e.g. a backup program in the process of replicating a directory tree containing links, it does matter to you, as you would want to create the same kind of link on the destination (if possible).
Why would you need to create the same kind of link (hard link) if a soft link can replace a hard link and will copy (as a link) to any OS4 Amiga filesystem? It's just going to slow down your backup program because it will need extra code to either detect what filesystem it is writing to or respond to a hard link creation failure and use a soft link anyway.
@all There are just some aspects of OS3 that just don't belong in a modern OS and hard links is one of them. OS4 should continue to be capable of reading hard links but create only soft links. A user can't tell the difference between an absolute (absolute path) soft link and a hard link. Why waste CPU time to identify and replicate hard links if there is no benefit in doing so.
At the very least, the OS4 "MakeLink" command needs default to soft links because most users don't know the difference and are puzzled by the failure of "MakeLink" when they enter it without the "SOFT" argument. Hard links are just a holdover from Floppy days and just create extra complications in OS4.
Amiga X1000 with 2GB memory & OS 4.1FE + Radeon HD 5450
Since most people are using SFS or JXFileSystem, you can't reproduce hard links on those filesystems anyway.
But as hard links are *possible* (and more people seem to use FFS than you might imagine), I still need to handle hard links.
You can say "just replace hard links by soft links", but if someone has hardlinks then they likely have a reason for using them.
The overhead is trivial anyway, so I can't see any reason not to
Quote:
Why would you need to create the same kind of link (hard link) if a soft link can replace a hard link and will copy (as a link) to any OS4 Amiga filesystem?
I don't have any recent experience with hardlinks, but from memory I recall that hardlinks do behave quite differently to soft links, in certain respects. At the very least I think:
1. If you make a hardlink, and then delete the original, the hardlink will still work because the filingsystem won't actually delete the file's contents until all references have been destroyed.
2. If you rename or move the target of a hard link, it will still keep working. If you rename or move the target of a soft link, it will stop working.
Quote:
At the very least, the OS4 "MakeLink" command needs default to soft links
@all Just a quick follow-up to warn people that the DoPkt3() implementation (of a link type check) does not work reliably, at least with SFS on OS4. I've gone back to my old (and rather slower) code.
A hard link is more like a backup of the file then a link to the file.
The two files shares the same blocks, but if some thing is changed then some of blocks are no longer sherd.
Some Linux tools try implement a incremental backups or time machine using rsync and hard links.
(Hard links works on some partition / disk.)
This saves a lot of disk space, but as soon as you burn it to CDR or copy it backup drive, then hard links are voided, and benefit’s are no longer there.
Edited by LiveForIt on 2013/1/14 23:43:58
(NutsAboutAmiga)
Basilisk II for AmigaOS4 AmigaInputAnywhere Excalibur and other tools and apps.
The two files shares the same blocks, but if some thing is changed then some of blocks are no longer sherd.
Are you SURE about that? On the Amiga I thought that hardlinked files ALWAYS share ALL blocks? i.e. A hard link is little more than an extra directory entry to the same file contents.
I did finally use my (seemingly correct) new understanding of GetDeviceProc()/etc to rewrite my broken code... and tests seem to show they do actually work! (Also they achieve what I originally set-out to do, which was get the correct result for a soft link that is not at the top of a multi-assignment.)
Unfortunately this then broke the reading of soft links containing *relative* paths (such as used by the SDK), for reasons I am not entirely clear on. Filer suffers from a similar but less severe problem (it always displays soft links as absolute paths, even when they are relative).
I ended-up reverting to my original ReadLink() code, but added code to handle any potential multi-assignments. Seems to work, although I wish I could have used ReadLink() without this 'kludge'.
Lets say you have database file that increases, the database file is 2GB large, every day you want a backup of it, because its so critical to your business, you simply can have that file corrupted, You business runs a Raid mirror setup so you have redundancy if one disk breaks.
days * 2Gbytes over a month period you have wasted, 62GBytes in a addition to the file you where backing up, but pronely a lot more because database is increasing as more and more data is put in to it, but lets say database only increases whit 2MB every month,
But whit hard links the backup file only consist of changes, while file looks the same only 2MB of new data is different from old backup, and thats the space it takes.
Edited by LiveForIt on 2013/1/12 17:10:08 Edited by LiveForIt on 2013/1/12 17:12:44 Edited by LiveForIt on 2013/1/14 23:41:16
(NutsAboutAmiga)
Basilisk II for AmigaOS4 AmigaInputAnywhere Excalibur and other tools and apps.
News feed
OS4 Feedback forum
OS4Depot Feedback forum
Amigabounty forum
OpenAmiga forum
AmiCygnix forum
ABC shell forum
AmiKit forum
Cinnamon Writer forum
CodeBench forum
Digital Universe forum
Dopus 5 forum
E-UAE forum
Gnash forum
Ibrowse forum
JAmiga forum
Odyssey forum
OWB forum
Qt forum
SmartFileSystem forum
Timberwolf forum
TouchDevice forum
TuneNet forum
Unsatisfactory Software forum
Donate
but I did finally use my (seemingly correct) new understanding of GetDeviceProc()/etc to rewrite my broken code... and tests seem to show they do actually work! (Also they achieve what I originally set-out to do, which was get the correct result for a soft link that is not at the top of a multi-assignment.)
