WB ignores "duplicates" on case-sensitive filesystems

[chris]

I've discovered a bug in Workbench. When used with a case-sensitive filesystem, if more than one object has the same name (ignoring case), Workbench will only ever show one of them. The dir command in the Shell will show both.

This is easier to explain with a screenshot, so in this example I have two drawers, one called "test" and the other "Test". Workbench only shows "Test", but dir shows both "Test" and "test":



You can see this behaviour quite easily using FTPMount and creating the two drawers or copying two files in and giving them names that only differ by case. It is not an FTPMount bug as I see exactly the same thing with the WebDAV handler I'm playing around with (in fact that FTP share in the screenshot is also a WebDAV share, so the data being looked at is identical with both filesystems)

[Slayer]

Hi there Chris

Perhaps you should have posted this in a more specific section unless you're saying you've confirmed it on all platforms running AmigaOS4.x

I'll confirm this behavior when I get home from work and enter it in bugzilla unless someone beats me too it

I used to run a case sensitive partition on occasion since some mud codebases I used to compile required it

For background information can you state what revision of AOS4 you are running and on what platform OR platforms you've discovered this on?

[chris]

Perhaps you should have posted this in a more specific section unless you're saying you've confirmed it on all platforms running AmigaOS4.x

I'll confirm this behavior when I get home from work and enter it in bugzilla unless someone beats me too it

I used to run a case sensitive partition on occasion since some mud codebases I used to compile required it

For background information can you state what revision of AOS4 you are running and on what platform OR platforms you've discovered this on?

Well, admittedly I haven't checked all platforms, but it isn't a hardware specific issue...

I spotted it on a SAM440EP running OS4.1u4

Thanks
Chris

[tonyw]

It's not necessarily a WB bug. WB only displays what it receives from the ExamineDir() DOS call. FTPMount is supplying that information, so it may be FTPMount that is the cause.

In the Shell case, C:dir is reading the remote directory and printing the results (and dir is very old) so it may be using a very different means of reading and interpreting the dir contents.

What is the remote filesystem? Is it Loonix?

[Slayer]

Okay, something is going on here I formatted an extra partition like so:

sfsformat drive dhb: name B CASESENSITIVE NORECYLED

so no FTPMount

Running a clean AOS4.1.5 X1000 installation

I'll do a bit of research and see what we can put it against

Testtest.jpg

(71.09 KiB) Downloaded 811 times

Bug # 7660

[chris]

It's not necessarily a WB bug. WB only displays what it receives from the ExamineDir() DOS call. FTPMount is supplying that information, so it may be FTPMount that is the cause.

In the Shell case, C:dir is reading the remote directory and printing the results (and dir is very old) so it may be using a very different means of reading and interpreting the dir contents.

With my handler I have debug in, so I can see that both are calling ACTION_EXAMINE_OBJECT/ACTION_EXAMINE_NEXT, there's not much else they can call at the filesystem level (especially when the 64-bit DOS packets aren't implemented ). Workbench loves creating locks on files, which could be the cause, except as we are getting it on three different handlers/filesystems (with Slayer's SFS test) it seems incredibly unlikely to be anything at that low level.

It could be dos.library, ExamineDir() vs Examine()/ExNext() I guess.

What is the remote filesystem? Is it Loonix?

Yep.

@Slayer
Thanks for confirming!