Login
Username:

Password:

Remember me



Lost Password?

Register now!

Sections

Who's Online
124 user(s) are online (69 user(s) are browsing Forums)

Members: 0
Guests: 124

more...

Headlines

 
  Register To Post  

« 1 (2) 3 »
Re: API hole? No way to find the full path of a link that is in a multi-assignment?
Home away from home
Home away from home


See User information
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()...

Author of the PortablE programming language.
Go to top
Re: API hole? No way to find the full path of a link that is in a multi-assignment?
Just can't stay away
Just can't stay away


See User information
@ChrisH
Quote:
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

Go to top
Re: API hole? No way to find the full path of a link that is in a multi-assignment?
Home away from home
Home away from home


See User information
@ChrisH

Don't forget to add your findings to the dev wiki, if possible

People are dying.
Entire ecosystems are collapsing.
We are in the beginning of a mass extinction.
And all you can talk about is money and fairytales of eternal economic growth.
How dare you!
– Greta Thunberg
Go to top
Re: API hole? No way to find the full path of a link that is in a multi-assignment?
Just can't stay away
Just can't stay away


See User information
Quote:
ChrisH wrote:

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()...
Ah, that sounds useful. Do share (on the Wiki?).

Best regards,

Niels

Go to top
Re: API hole? No way to find the full path of a link that is in a multi-assignment?
Amigans Defender
Amigans Defender


See User information
@ssolie

Excellent!

Go to top
Re: API hole? No way to find the full path of a link that is in a multi-assignment?
Home away from home
Home away from home


See User information
@nbache Quote:
that sounds useful. Do share

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.

Author of the PortablE programming language.
Go to top
Re: API hole? No way to find the full path of a link that is in a multi-assignment?
Just popping in
Just popping in


See User information
>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.

Go to top
Re: API hole? No way to find the full path of a link that is in a multi-assignment?
Amigans Defender
Amigans Defender


See User information
@Minuous

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.

Go to top
Re: API hole? No way to find the full path of a link that is in a multi-assignment?
Home away from home
Home away from home


See User information
@Minuos

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.




Go to top
Re: API hole? No way to find the full path of a link that is in a multi-assignment?
Just can't stay away
Just can't stay away


See User information
@broadblues

Quote:

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.

Go to top
Re: API hole? No way to find the full path of a link that is in a multi-assignment?
Just can't stay away
Just can't stay away


See User information
@ChrisH
Quote:
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

Go to top
Re: API hole? No way to find the full path of a link that is in a multi-assignment?
Just can't stay away
Just can't stay away


See User information
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).

Best regards,

Niels

Go to top
Re: API hole? No way to find the full path of a link that is in a multi-assignment?
Home away from home
Home away from home


See User information
@xenic Quote:
For OS4 there really isn't a need to distinguish between hard and soft links.

As nbache said, if *does* matter if one is intending to backup links! As both my AmigaAttributes & AmiSystemRestore programs need to do

Author of the PortablE programming language.
Go to top
Re: API hole? No way to find the full path of a link that is in a multi-assignment?
Just can't stay away
Just can't stay away


See User information
@ChrisH
Quote:
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

Go to top
Re: API hole? No way to find the full path of a link that is in a multi-assignment?
Home away from home
Home away from home


See User information
Quote:
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

Yes, I agree on this.

Author of the PortablE programming language.
Go to top
Re: API hole? No way to find the full path of a link that is in a multi-assignment?
Home away from home
Home away from home


See User information
@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.

Author of the PortablE programming language.
Go to top
Re: API hole? No way to find the full path of a link that is in a multi-assignment?
Home away from home
Home away from home


See User information
@xenic

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.
Go to top
Re: API hole? No way to find the full path of a link that is in a multi-assignment?
Home away from home
Home away from home


See User information
@LiveForIt Quote:
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.

Author of the PortablE programming language.
Go to top
Re: API hole? No way to find the full path of a link that is in a multi-assignment?
Home away from home
Home away from home


See User information
I wrote Quote:
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'.

Author of the PortablE programming language.
Go to top
Re: API hole? No way to find the full path of a link that is in a multi-assignment?
Home away from home
Home away from home


See User information
Quote:
Are you SURE about that? On the Amiga I thought that hardlinked files ALWAYS share ALL blocks?


Yes on Linux/Unix/MacOSX, I do not know if its working on AmigaOS probably not.

If you just google it you find a lot of information about that RSync nad Hardlinks.

http://brian.windheim.org/2012/time-m ... e-sucks-use-rsync-instead

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.
Go to top

  Register To Post
« 1 (2) 3 »

 




Currently Active Users Viewing This Thread: 1 ( 0 members and 1 Anonymous Users )




Powered by XOOPS 2.0 © 2001-2023 The XOOPS Project