How do I set file information on a *link*

This forum is for general developer support questions.
xenic
Posts: 1185
Joined: Sun Jun 19, 2011 12:06 am

Re: How do I set file information on a *link*

Post by xenic »

colinward wrote:@Colin Wenzel, if I raised a Buzgilla asking for Windows style "perform this operation on the link, not on the file it points to" functionality, would there be a chance of it being implemented?
I can't speak for Colin but I don't think it's possible without changing the filesystems. I ran some tests with dospackets (ACTION_SET_DATE) and FFS seems to change the link date while SFS and RAM return an error code. Even if Colin changed the way IDOD->SetDate() works, you would get inconsistant results from the existing filesystems. By changing the date on the file a link points to, IDOS->SetDate() is at least providing consistant results regardless of the filesystem.
AmigaOne X1000 with 2GB memory - OS4.1 FE
User avatar
tonyw
AmigaOS Core Developer
AmigaOS Core Developer
Posts: 1479
Joined: Wed Mar 09, 2011 1:36 pm
Location: Sydney, Australia

Re: How do I set file information on a *link*

Post by tonyw »

Did you try to send a DOS Packet directly to ram-handler? Because it would have been rejected by the handler and emulated as an IDOS->SetDate() call.

Your point is valid, though - since this behaviour was never defined for legacy filesystems like FFS or SFS, how they implement such a call is up to each FS.
cheers
tony
User avatar
colinw
AmigaOS Core Developer
AmigaOS Core Developer
Posts: 207
Joined: Mon Aug 15, 2011 9:20 am
Location: Brisbane, QLD. Australia.

Re: How do I set file information on a *link*

Post by colinw »

xenic wrote: I ran some tests with dospackets (ACTION_SET_DATE) and FFS seems to change the link date while SFS and RAM
return an error code.
Then you may have found an old bug with FFS, because the ONLY response to a filesystem action on the
softlink name, for all calls other than ACTION_MAKE_LINK, ACTION_DELETE_OBJECT, ACTION_READ_SOFT_LINK
(and conditionally) ACTION_RENAME_OBJECT, is a primary failure code and ERROR_IS_SOFT_LINK in result2.

This is how DOS is told by the filesystems when to resolve a softlink and is how softlinks work in AmigaDOS.
It's all in the autodocs.
xenic
Posts: 1185
Joined: Sun Jun 19, 2011 12:06 am

Re: How do I set file information on a *link*

Post by xenic »

colinw wrote:Then you may have found an old bug with FFS
Maybe when softlinks in FFS were fixed for AmigaOS v37 or when OS4 FFS was created, the response to ACTION_SET_DATE was overlooked and FFS is treating hard and soft links the same. Of course that's just conjecture on my part.

Going a little off topic: FTPMount stopped working for me as of OS4.1FE so I updated the code for my own use with FE. In addition to updating the code to compile with the latest SDK, I had to change the dospacket handling. The handler was receiving packets, altering some arguments (while saving the original args) and forwarding the packets to another FTPMount process to perform the requested action. The packets were then returned to the main process, the original arguments restored and the packet replied back to DOS. It took me many hours to determine that the packet forwarding was causing the failures and change the way the args are forwarded. Is OS4.1FE AmigaDOS somehow detecting when packets are reused and causing failure?? It worked up to Update 6.
AmigaOne X1000 with 2GB memory - OS4.1 FE
xenic
Posts: 1185
Joined: Sun Jun 19, 2011 12:06 am

Re: How do I set file information on a *link*

Post by xenic »

tonyw wrote:Did you try to send a DOS Packet directly to ram-handler? Because it would have been rejected by the handler and emulated as an IDOS->SetDate() call.

Your point is valid, though - since this behaviour was never defined for legacy filesystems like FFS or SFS, how they implement such a call is up to each FS.
Assuming that dvp = IDOS->GetDeviceProc("Ram:", NULL) worked as it should and that dvp->dvp_Port is the ram-handler port, then the DOS packet was sent directly to ram-handler. I only saw the result so I have no way of knowing if it was emulated or not.

There are also other inconsistancies between filesystems.
AmigaOne X1000 with 2GB memory - OS4.1 FE
User avatar
colinw
AmigaOS Core Developer
AmigaOS Core Developer
Posts: 207
Joined: Mon Aug 15, 2011 9:20 am
Location: Brisbane, QLD. Australia.

Re: How do I set file information on a *link*

Post by colinw »

xenic wrote: Assuming that dvp = IDOS->GetDeviceProc("Ram:", NULL) worked as it should and that dvp->dvp_Port
is the ram-handler port, then the DOS packet was sent directly to ram-handler. I only saw the result so I have no way
of knowing if it was emulated or not.
There are also other inconsistancies between filesystems.
There are always inconsistencies between filesystems, that's what the dos.library layer tries very hard to
abstract from applications. And now, there are two completely different styles of handlers that can co-exist too.

As far as telling what type of handler you have, that's easy....
if( IDOS->GetFileSystemVectorPort(port,53) ) then it's a vector-port style filesystem handler,
else, it's a dospacket based handler.

If it's a vector-port based filesystem, chucking dospackets down its throat, is not likely to have the expected
response if you do "funny stuff", because it will just say, "what the heck is this thing at my message port ?".
The filesystem will then call dos.library via the fsvp->FSV.DOSEmulatePacket() to try and make sence of what
it found and turn the old dospacket action into an equivalent vector-port function call using the action type
number and parameters supplied in the dospacket. It will then place the result of the function call back into
the result1 and result2 of the same dospacket and return, the filesystem will then ReplyMsg() and you get your
dospacket back, with the two result values. That's the limit of what it does.
Also, it only does it for the standard dospacket action types it expects, if you give an action that is unsupported,
you are likely to get ERROR_ACTION_NOT_KNOWN and a notification requester in your face.

So, the basic moral to this story is, don't do dospacket operations to filesystems from applications anymore.

You will not only slow the calls way way down for VectorPort filesystems, but your application will be limited
to just the packets supported by the dos.library packet emulator and some things like DOS notifications,
DOS record locks and maybe some other features, won't be available to you.

Always call the dos.library API functions when possible, because thats where the compatibility layer and
extended functions and features are located.
Post Reply