Filesystem links

Links seems to behave a bit oddly in OS4.

1.
ExamineDir() reports a softlink to a file as a directory. ExamineObjectTags() reports the same softlink as a file.

(using EXT_IS_SOFTLINK(), EXD_IS_FILE() in both cases)

2.
Creating a hardlink to a file in ram: and then editing the file (not the link) turns the hardlink into a file. (odd but perhaps normal?)

3.
Hardlinks have the full path in ExamineData.Link (including device name)
Soflinks does not have the device name in ExamineData.Link

@orgin

Number 2 sounds like a bug in the ram disk to me, hard links are supposed to be the same object on disk, so editing one should change both.

BTW the converse seems to be true too, editing the hard link separates the two.

@orgin

> Links seems to behave a bit oddly in OS4.
> 1.
> ExamineDir() reports a softlink to a file as a directory.

Not here, it is reported correctly as a SOFTLINK by ExamineDir()
0x0100 = FSOF_LINK(0x0100) | FSO_TYPE_SOFTLINK (0x00)

5.RAM Disk:> makelink ram:SL_loadwb c:loadwb SOFT
5.RAM Disk:> examinedir

struct ExamineData
{
struct MinMode EXDnode = 0x69F524A4, 0x69F524A0
uint32 EXDinfo = 0x00000000
uint32 FSPrivate[2] = 0x00000000, 0x00000000
APTR DOSPrivate = 0x69F52490
uint32 StructSize = 116
int32 Type = 0x0100 (SOFTLINK)
int64 FileSize = -1
struct DateStamp Date = 11431, 567, 2455
uint32 UseCount = 0
uint32 Reserved1 = 0
uint32 ObjectID = 0
STRPTR Name = "SL_loadwb"
uint32 NameSize = 10
STRPTR Comment = ""
uint32 CommentSize = 1
STRPTR Link = "c:loadwb"
uint32 LinkSize = 32
uint32 Protection = 0x00000000
uint32 OwnerUID = 0x00000000
uint32 OwnerGID = 0x00000000
uint32 Reserved2 = 0x00000000
uint32 Reserved2 = 0x00000000
uint32 Reserved2 = 0x00000000
};


> ExamineObjectTags() reports the same softlink as a file.
> (using EXD_IS_SOFTLINK(), EXD_IS_FILE() in both cases)


ExamineObject() is what RESOLVES the link, that's how it works.
Nothing new there.

5.RAM Disk:> examineobject SL_loadwb

struct ExamineData
{
struct MinNode EXDnode = 0x00000000, 0x00000000
uint32 EXDinfo = 0x00000000
uint32 FSPrivate[2] = 0x00000000, 0x00000000
APTR DOSPrivate = 0x00000000
uint32 StructSize = 116
int32 Type = 0x0001 (FILE)
int64 FileSize = 5016
struct DateStamp Date = 11220, 1121, 772
uint32 UseCount = 0
uint32 Reserved1 = 0
uint32 ObjectID = 0
STRPTR Name = "LoadWB"
uint32 NameSize = 108
STRPTR Comment = ""
uint32 CommentSize = 80
STRPTR Link = ""
uint32 LinkSize = 1
uint32 Protection = 0x0000AA20
uint32 OwnerUID = 0x00000000
uint32 OwnerGID = 0x00000000
uint32 Reserved2 = 0x00000000
uint32 Reserved3 = 0x00000000
uint32 Reserved4 = 0x00000000
};


> 2.
> Creating a hardlink to a file in ram: and then editing the file
> (not the link) turns the hardlink into a file. (odd but perhaps normal?)


Yes it does, hardlinks do wierd things on different filesystems,
that is, if they actually are supported at all.
Use SOFTLINKS and that sort of wierdness won't happen.


> 3.
> Hardlinks hand the full path in ExamineData.Link (including device name)
> Soflinks does not have the device name in ExamineData.Link

It's going to be what was specified when creating the link,
and can often be current dir relative, but then again, refer to (2)


Check your code against the examples in the autodoc, you may be doing
something wrong, or missing a particular data type specifier flag, or evaluating out of order.
Always check EXD_IS_LINK() first.

@orgin

Quote:With FFS and ram-handler: Yes.
They don't have usual hard links but a strange implementation which only exists on AmigaOS, one of the links has to be a file and if you delete the link which is currently the file one of the other links has to be converted into a file instead.

@colinw

"Not here, it is reported correctly as a SOFTLINK by ExamineDir()
0x0100 = FSOF_LINK(0x0100) | FSO_TYPE_SOFTLINK (0x00)"

That's odd, i doesn't do that here. (yes I check link first, then type). It works for hard links but not soft links. For soft links I now have a workaround that does ExamineObjectTags() on each entry that reports as a soft link when listing a directory. (tested on SFS and RAM with the same result, 4.1 non beta)

"Yes it does, hardlinks do wierd things on different filesystems,
that is, if they actually are supported at all.
Use SOFTLINKS and that sort of wierdness won't happen."

Hmm not so easy to support them in a file manager then since the outcome of accessing them can be a bit random.

"It's going to be what was specified when creating the link, "

Is there a way to resolve the complete path with device name (without writing my own parser that is)? In my file manager I want to go to the actual path when clicking a directory link since using just the current path + linkname can results in errors such as "too many levels" when trying to create a file/directory or just opening a file in notepad.

@orgin

"That's odd, i doesn't do that here. (yes I check link first, then type). It works for hard links but not soft links. For soft links I now have a workaround that does ExamineObjectTags() on each entry that reports as a soft link when listing a directory."

Huh ? - That's exactly how you resolve the link.
When you ExamineObject() a softlink you get the
object it is linked to, it's supposed to work like that.
You need to see how to resolve links, consult the autodoc
for ExamineDir() - NOTES section.


What filesystem are you using there ?,
Have you tried other filesystem partitions ?,
What hex VALUE is in exdata->Type for that entry from ExamineDir() ?

I'll send you a test program privately....
Send me a blank email so I can get your address if you want it.

@colinw

"Huh ? - That's exactly how you resolve the link.
When you ExamineObject() a softlink you get the
object it is linked to, it's supposed to work like that.
You need to see how to resolve links, consult the autodoc
for ExamineDir() - NOTES section."

Ahh, nice that I unintentionally ended up doing what I was supposed to do then ;)

"What filesystem are you using there ?,"
"Have you tried other filesystem partitions ?,"
Ram and sfs

What hex VALUE is in exdata->Type for that entry from ExamineDir() ?

Always 0xFF.

@orgin

SNapshot: http://orgin.biz/~orgin/images/filerlinks.png

@orgin
"What hex VALUE is in exdata->Type for that entry from ExamineDir() ?"
"Always 0xFF."


0xFF good grief, there is no object type 255, they only
go up to 4 currently. It's a nonsence value.

I hope you didn't forget to specify EXF_TYPE in the mask
for your call to ObtainDirContextTags() with the
EX_DataFields tag ??

Hmmmm ??

@colinw

Autodoc says:

"Default = EXF_ALL when tag not supplied."

@broadblues

Quote:

On JXFS if you try to create a hard link, it just creates a copy of the file instead.

@Chris

Quote:No, it creates a hard link. Just a real one, like for example on Unix, not the weird FFS hard links, and most AmigaOS programs can't identify them as hard links (ExamineData UseCount is > 1 and all directory entries have the same ObjectID).

@joerg

Hmm, well there's something wrong as if I create a file "test1"
makelink test2 test1
and then edit test2, the contents of test1 don't change as they should.

@Chris

Quote:If you change test2, for example using "echo >>test2 foobar" in a shell, the contents of both changes.
Most editors don't change the file, they delete the old one and create a new one instead and if that's done test1 and test2 are of course different files, for example "echo >test2 foobar" in a shell does that as well.

@joerg

That makes sense, thanks for the explanation.