Hyperion Entertainment Message Boards

Hi devs,

i found a little misbvehaviour which is freaking me out for a long time now, just wanted to ask if it is by design or can be considered a "bug"?

Steps to reproduce:

1) Create a dir called root in ram:
2) cd to ram:root
3) create a dir called Dirt (mind the uppercase first letter)

4) create a dir called dirt (mind the lower case letter) on another partition or any hdd
5) drag and drop the dir "dirt" from the hdd into ram:root

6) the directory in ram:root will be renamed to dirt (lower case)

Now, while i could live with the example avove it becomes a nuisance when i only want to copy the files inside this directory

i.e if i want to add some drivers to devs which don't have an installer, i simply d&d them to my sys: partition, but everytime i do so "Devs" (original naming by the AmigaOS4 CD installer) gets renamed to whatever "DeVS" name the author of the driver chose for it's subdir.

Is this intended?

I tried recreating this, both on a current public installation and on my beta installation.

It does not happen for me, at least not if I follow your description exactly.

But I have found a way to make something similar happen, which might be what you have seen.

If the "dirt" drawer on the HD has an icon (i.e. the file "HDx:dirt.info" exists), but the "Dirt" drawer in RAM: does not have one (i.e. the file "RAM:root/Dirt.info" does not exist), then when you drag the drawer icon "Dirt" on top of the "root" drawer in WB, or inside its opened window, the previous deficon called "Dirt" in the "RAM:root" drawer is replaced by the copy of the real icon "dirt" dragged from the HD.

This is only natural, because you actually copy the file "dirt.info" into "RAM:root", where no .info file existed previously, and WB will always display the icon based on the .info file, if one exists.

To further show this, try the same case again, but this time create icons for both drawers, i.e. also for "RAM:root/Dirt" (so the file "RAM:root/Dirt.info" exists). Now if you attempt the drag-copy again, you should get a requester because the file "Dirt.info" already exist, and you attempt to overwrite it (with the copied "dirt.info").

All in all, I personally don't see this as a bug, but simply "the way WB works".

(Now excuse me while I clean the "dirt" from my HD ).

Best regards,

Niels

@nbache

Yes, your example is logical

What i forgot in my example is to tell you to snapshot both Root and Root/Dirt in RAM: thus giving them .info files but NOT the dirt dir that will be copied.
Could you please repeat with snapshot dirs in RAM: and copy a non-snapshotted dirt into Root (or into the open Root window) please?
Because this will be the behaviour i was describing.

Now an ".info-less" directory will rename a snapshotted directory.

In this example there are only dirs to be copied, but imagine there are files in the dirt dir.
(Like when you drag a new driver to System:Devs. If it sits in an unsnapshotted devs it will rename Devs to devs aswell)
The problem i see here is that i don't want to rename the directory structure but only move/copy the files inside the last directory.

Hope i got it clear this time

Thanks for looking

Okay, I can see this. It doesn't really rename the directory, though, only the .info file, but that is still not logical.

But I also tried this on the current beta with the newer ram-handler, and there it works better. The directory *and* the .info file are both kept un-renamed, but Workbench seems to still believe the name was changed, as the "Dirt" drawer in the open "root" window is now shown with the name "dirt". But if I close both the "root" and the "RAM Disk" windows and open them again, it now displays the original name of "Dirt". And checking in DOpus and with List confirms this: It was not really renamed.

So the renaming issue seems to be solved in the latest beta, only a small WB glitch remains. I'll have to look closer into that and make a report, so we can (hopefully) get rid of that last issue as well.

Thanks for reporting.

Best regards,

Niels

nbache wrote: ...snip...

So the renaming issue seems to be solved in the latest beta, only a small WB glitch remains. I'll have to look closer into that and make a report, so we can (hopefully) get rid of that last issue as well.

Thanks for reporting.

Best regards,

Niels

Thanks a lot, Niels

There is also a related bug which annoys me:

If you copy an iconless drawer into a WB window which already contains a iconed drawer of that name, the existing icon re-snapshots itself at the point the non-icon drawer was dragged in.

Not sure how much sense that makes but hopefully enough to reproduce it.

chris wrote:There is also a related bug which annoys me:

If you copy an iconless drawer into a WB window which already contains a iconed drawer of that name, the existing icon re-snapshots itself at the point the non-icon drawer was dragged in.

Not sure how much sense that makes but hopefully enough to reproduce it.

It makes perfect sense and i would have taken this specific information into my first report if i had thought about it.

Yes, it does and if i copy a non-snapshot dir containing new files into my SYS: partition i always copy it into the PARENT drawer to avoid the effect you describe.

Thanks for mentioning it.

@nbache

Maybe you can add that to the bug item or open a new report, please?

Raziel wrote:

chris wrote:If you copy an iconless drawer into a WB window which already contains a iconed drawer of that name, the existing icon re-snapshots itself at the point the non-icon drawer was dragged in.

@nbache

Maybe you can add that to the bug item or open a new report, please?

Yes, I actually saw that as well during my test. Thanks for reminding me.

Best regards,

Niels

After some experimenting, it turns out these two issues are unrelated. If you deactivate ASyncWB, the re-snapshotting does not happen, but the temporary change of name in WB still does. So the former is an issue with ASyncWB, while the latter is in WB itself.

I'll make reports for both.

Best regards,

Niels

The re-snapshotting turns out to have been reported in Bugzilla already. I added a comment and a pointer to this thread.

The change of case issue wasn't there, but has now been registered.

Thanks for the reports, both of you.

Best regards,

Niels