Two problems introduced by Update 5

[nbache]

The new filesystem version is

SmartFilesystem 1.290 (01/21/2011)

whereas the one I had before was

SmartFilesystem 1.286 (11/25/2009)

Any idea anyone?

Just one, perhaps a bit wild one: What happens if you empty your .recycled dir on the SFS volume and run your make command again? I was just thinking that if maybe your volume was actually close to full (counting in all the deleted files in .recycled), then maybe that would cause delays while SFS looked for old deleted files to purge in order to make room for new ones created/deleted during the make process?

Best regards,

Niels

[saimo]

Just one, perhaps a bit wild one: What happens if you empty your .recycled dir on the SFS volume and run your make command again? I was just thinking that if maybe your volume was actually close to full (counting in all the deleted files in .recycled), then maybe that would cause delays while SFS looked for old deleted files to purge in order to make room for new ones created/deleted during the make process?

Indeed very wild (since that makefile does not create files). Anyway, I can report that nothing changes.

[nbache]

Indeed very wild (since that makefile does not create files).

Not even temporary ones?

Anyway, I can report that nothing changes.

Oh well, worth a shot.

Best regards,

Niels

[tonyw]

@Saimo:

What should be found is what in my system causes such a behaviour...

Quite right, and only you can find that out. Unless you are prepared to isolate the problem as I have described, we can't help you.

[samo79]

Problem may be related to the new SmartFilesystem 1.290, i installed each Update in turn, --> Update 2, 3, 4 and the 5
My main SYS: partition infact seems ok, but all the other partitions i created before (with the old SmartFileSystem) still have some strange issue from time to time, for example there is some "little slow" accessing the directory, some errors from time to time --> see thread: http://forum.hyperion-entertainment.biz ... =14&t=1240

I also note another strange issue, "Find" sometimes doesn't work, it start but when you enter a string to search nothing happen, i think again it may be Filesystem related

For now that are the only problems i have with Update 5

[Belxjander]

Problem may be related to the new SmartFilesystem 1.290, i installed each Update in turn, --> Update 2, 3, 4 and the 5
My main SYS: partition infact seems ok, but all the other partitions i created before (with the old SmartFileSystem) still have some strange issue from time to time, for example there is some "little slow" accessing the directory, some errors from time to time --> see thread: http://forum.hyperion-entertainment.biz ... =14&t=1240

I also note another strange issue, "Find" sometimes doesn't work, it start but when you enter a string to search nothing happen, i think again it may be Filesystem related

For now that are the only problems i have with Update 5

makes me feel better to have mirrored my reservation install for every update! separately

[abalaban]

makes me feel better to have mirrored my reservation install for every update! separately

It's always recommended to have a backup at hand when applying any update for any operating system...

[saimo]

Problem may be related to the new SmartFilesystem 1.290, i installed each Update in turn, --> Update 2, 3, 4 and the 5
My main SYS: partition infact seems ok, but all the other partitions i created before (with the old SmartFileSystem) still have some strange issue from time to time, for example there is some "little slow" accessing the directory, some errors from time to time --> see thread: http://forum.hyperion-entertainment.biz ... =14&t=1240

I also note another strange issue, "Find" sometimes doesn't work, it start but when you enter a string to search nothing happen, i think again it may be Filesystem related

For now that are the only problems i have with Update 5

I just would like to clarify that I have no filesystem problem whatsoever: no pauses, no errors, nothing. I even ran a test for disk access that I do after every update, and this time the results turned out to have improved sensibly. (I usually share those benchmarks on Amigans.net, but this time I could not do it yet.)
F.ex., only a small fraction of second is needed to produce the listing of my whole data partition - for precision's sake, the command List data:#? ALL >RAM:log generates a 497 kB file of entries like this:

Code: Select all

Directory "data:" on Friday 24-Aug-12
temporary.info                 5306 ----rw-d 14-Jun-12 23:54:58
Disk.info                      3646 ----rw-d 06-Jun-12 22:10:33
videos                          Dir ----rw-d 17-Jun-12 18:25:11
instruments                     Dir ----rw-d 05-Apr-12 22:43:41
miscellaneous                   Dir ----rw-d 06-Jul-12 00:27:07
music                           Dir ----rw-d 29-Jul-12 22:13:55
pictures                        Dir ----rw-d 08-Jun-12 18:17:46
my stuff                        Dir ----rw-d Tuesday   18:46:16
.backdrop                        11 ----rw-d 03-Feb-12 21:13:27
temporary                       Dir ----rw-d Today     19:04:17
documentation                   Dir ----rw-d 22-May-12 22:31:35
3 files - 8K bytes - 8 directories - 39 blocks used

...

TOTAL: 6795 files - 10G bytes - 341 directories - 21310454 blocks used

[saimo]

Quite right, and only you can find that out. Unless you are prepared to isolate the problem as I have described, we can't help you.

Just to avoid any misunderstanding, first let me clarify that I'm writing the following with the friendliest intentions and tone I'm capable of, and for the sake of AmigaOS and the community (given that, as already said, I personally am not affected at all about this MultiView problem - in fact, it came out only because you suggested to make a test with it, but I have never copied a piece of text in my life from MultiView, as I simply don't use it). Also, the fact that I'm here making tests and reporting as accurately as I can, despite I'd have a much better use for my little spare time, should be a sign of my willingness to help (again, in this specific case, it's me trying to help, not the other way around)

That said, back to the topic...
Making tests on a fresh installation is useless not only because of the reasons already explained, but also because AmigaOS is a product that will end up in the hands of many (and lets hope lots of) people, and each and every one will have a system of his own, in one way or another: AmigaOS will have to be robust to perform as well as possible under the most disparate conditions - operating correctly when freshly installed is only the starting point.
On my system something doesn't work: it could be that I did something wrong, that something went wrong, or that there's something wrong in the OS... who knows, but let's find out testing this specific system! - this is the system where the conditions that cause the problem exist and, therefore, such system is a precious resource for bug hunting, since being able to reproduce problems is fundamental for such a task.

So, on with the tests...
I had said that I'd have checked with Snoopy, and so I did.
I have enabled all the traces supported by Snoopy and this is the result given by running MultiView from shell:

Code: Select all

Log Generated by; Snoopy 53.28 (7.7.2012)

00001 : Shell Process   : FAIL = FindVar("applications:MultiView",LV_ALIAS) = 0x00000000 [7uS]
00002 : Shell Process   : FAIL = FindSegment("applications:MultiView",0x00000000,USER) [14uS]
00003 : Shell Process   : FAIL = FindSegment("applications:MultiView",0x00000000,SYSTEM) [1uS]
00004 : ENV/env-handler 52.2  : FAIL = Lock("ENVARC:ELF.LazyBinding",SHARED) [39uS]
00005 : MultiView       : FAIL = Open("PROGDIR:Catalogs/english/Sys/utilities.catalog",OLD) = [0x00000000] [39uS]
00006 : MultiView       : FAIL = Open("LOCALE:Catalogs/english/Sys/utilities.catalog",OLD) = [0x00000000] [71uS]
00007 : MultiView       : FAIL = Open("PROGDIR:Catalogs/english_UTF-8/Sys/utilities.catalog",OLD) = [0x00000000] [21uS]
00008 : MultiView       : FAIL = Open("LOCALE:Catalogs/english_UTF-8/Sys/utilities.catalog",OLD) = [0x00000000] [38uS]
00009 : MultiView       : FAIL = Open("PROGDIR:Catalogs/english_US_ASCII/Sys/utilities.catalog",OLD) = [0x00000000] [20uS]
00010 : MultiView       : FAIL = Open("LOCALE:Catalogs/english_US_ASCII/Sys/utilities.catalog",OLD) = [0x00000000] [37uS]
00011 : MultiView       : FAIL = Open("PROGDIR:Catalogs/english/Sys/libs.catalog",OLD) = [0x00000000] [20uS]
00012 : MultiView       : FAIL = Open("LOCALE:Catalogs/english/Sys/libs.catalog",OLD) = [0x00000000] [38uS]
00013 : MultiView       : FAIL = Open("PROGDIR:Catalogs/english_UTF-8/Sys/libs.catalog",OLD) = [0x00000000] [20uS]
00014 : MultiView       : FAIL = Open("LOCALE:Catalogs/english_UTF-8/Sys/libs.catalog",OLD) = [0x00000000] [151uS]
00015 : MultiView       : FAIL = Open("PROGDIR:Catalogs/english_US_ASCII/Sys/libs.catalog",OLD) = [0x00000000] [25uS]
00016 : MultiView       : FAIL = Open("LOCALE:Catalogs/english_US_ASCII/Sys/libs.catalog",OLD) = [0x00000000] [40uS]
00017 : ENV/env-handler 52.2  : FAIL = Lock("ENVARC:MultiView",SHARED) [42uS]
00018 : MultiView       : FAIL = GetVar("MultiView/Workbench",0x5C3CE910,30,0x00000D00) [363uS]
00019 : MultiView       : FAIL = Lock("REXX:MultiView",SHARED) [174uS]
00020 : AsyncLayoutDaemon : <----- PRIVATEInternalRunCommand("<untracked>", ARG:"<NULL>") = [30026420 (0x01CA2AB4)]

Please note that trying to mark/copy generates no output (i.e. the above is what's generated at startup).

Finally, one question: earlier in this thread buttons are mentioned, but I've never ever seen buttons in MultiView... is that because the program offers a stripped-down interface only if catalogs are missing (as shown in the log)?

[nbache]

Just to avoid any misunderstanding, first let me clarify that I'm writing the following with the friendliest intentions and tone I'm capable of, and for the sake of AmigaOS and the community (given that, as already said, I personally am not affected at all about this MultiView problem - in fact, it came out only because you suggested to make a test with it, but I have never copied a piece of text in my life from MultiView, as I simply don't use it). Also, the fact that I'm here making tests and reporting as accurately as I can, despite I'd have a much better use for my little spare time, should be a sign of my willingness to help (again, in this specific case, it's me trying to help, not the other way around)

Absolutely, and we (beta testers etc.) are happy for any help you can give finding this issue - seeing as we can't reproduce it on our own systems. So we depend on your willingness to help isolating the faulty component(s) even if this might not benefit yourself in the end (as you don't use Multiview).

Making tests on a fresh installation is useless not only because of the reasons already explained, but also because AmigaOS is a product that will end up in the hands of many (and lets hope lots of) people, and each and every one will have a system of his own, in one way or another: AmigaOS will have to be robust to perform as well as possible under the most disparate conditions - operating correctly when freshly installed is only the starting point.

Of course noone expects all users to refrain from customising their installed system, and ideally AmigaOS should function equally well on them all. But in practice, we beta testers cannot possibly cover testing with all the possible permutations of programs installed, settings changed and hardware connected etc. So when an update is nearing release, the focus is on testing it with a virgin setup, so that we have a common firm ground where we "know" things should work.

So the reason for asking for a test with a fresh installation is to compare with what we tested (and/or can test again) on our own systems. Now there are two possibilities. One is that it works under the fresh installation, in which case we have to start installing and modifying step by step until we find the item which has some sort of problem with the update. The other is that it still doesn't work, and then we will have to look at things like hardware setup (maybe finding a beta tester who can duplicate that setup and - hopefully - reproduce the problem).

On my system something doesn't work: it could be that I did something wrong, that something went wrong, or that there's something wrong in the OS... who knows, but let's find out testing this specific system! - this is the system where the conditions that cause the problem exist and, therefore, such system is a precious resource for bug hunting, since being able to reproduce problems is fundamental for such a task.

Absolutely. But we need to be able to reproduce it on a beta tester's (or even better, the relevant developer's) system, and that requires isolating the relevant part of the setup which makes the problem appear or disappear. Of course this could theoretically also be done by removing stuff step by step from your system, until copy/paste works, but in practice it is much easier to go the opposite way as described above.

Best regards,

Niels