YAM overwrites the settings of my incoming folder on startup

default .fconfig for incoming placed there by YAM

.fconfig with my customisations

Replying to broadblues:

For the past couple of weeks or so, I've been seeing a strange problem with YAM overwriting the .fconfig file for my incoming folder.
I like to have appicon stats shown and mails order by date received, each time I set this I have checked the .fconfig file and sen that it is updated, but when I restart YAM, YAM replaces the file with a default.

The two files don't look suspicious in any way and I am able to modify my Incoming folder's settings to match yours without any negative effect, no matter which version I use (2.6p1, 2.7, 2.8-dev).

I think it would help if you can provide a debug log created with the debug version of YAM. A "all" log should reveal the problem on your machine, but beware, the log will become quite big.

Did you think about upgrading to YAM 2.7 yet? It offers great speed improvements for folders with lots of mails.

[quote]
I think it would help if you can provide a debug log created with the debug version of YAM. A "all" log should reveal the problem on your machine, but beware, the log will become quite big.
quote

I tried the YAM 2.6p1 debug version. With no debug set I get the same problem. I set the DEBUG\S switch on the command line and the problem did not occur. I only got a small amount of debug relating to client / server interaction.

I couldn't see how to vary the debug level, to show more info.

[quote]
Did you think about upgrading to YAM 2.7 yet? It offers great speed improvements for folders with lots of mails.
quote

Due to beta testing MUI I was waiting till that had passed as then I would be sure any changes were down to MUI not YAM. (NB this issue occurs with any version of MUI and I do not believe it to related to that testing)

Serial debug with yamdebug set to all

Serial debug with yamdebug set to all

I found the FAQ and realised that the DEBUG switch on the command line had thrown me off the sent and that the "real debug" was on the serial line....

Attached is a debug log of a short session.

At the end of the last YAM session I had set stats to on and message order to date received.

When YAM had started on this session again the incoming settings had reverted to default.

I then set them back to my prefered settings and quite YAM.

[edit] typo edit

Notice line 411 / 412 of the log says

FileInfo.c:62:getting file information 5 of file 'Work:NetApps/YAM/incoming'

YAM_FO.c:391:potential invalid fopen call with return (0x00000000, 0x00000001)

Yet I can open the .fconfig file in an editor and / or view in multiview etc.

Odd.

Replying to broadblues:

FileInfo.c:62:getting file information 5 of file 'Work:NetApps/YAM/incoming'

YAM_FO.c:391:potential invalid fopen call with return (0x00000000, 0x00000001)

Yet I can open the .fconfig file in an editor and / or view in multiview etc.

This very much smells like YAM tries to find the .fconfig file in the wrong place. Of course you can read the file if you know where to look for it.

I will build a slightly extended debug version of YAM 2.6p1 which will include the full path of the .fconfig file in the debug log. Please create another debug log with that version. A "FOLDER" debug log should be sufficient, no need .

Please attach your .folders file to this ticket and I need to know the MAILDIR ToolType of YAM's icon. I think there is something wrong with the pathes YAM has to work with. Did you change anything in this respect?

debug with ext3ended debug version. yamdebug set to FOLDER

current .folders file

Yet I can open the .fconfig file in an editor and / or view in multiview etc.

This very much smells like YAM tries to find the .fconfig file in the wrong place. Of course you can read the file if you know where to look for it.

Indeed. But it shows the files appears normal to other apps.

I will build a slightly extended debug version of YAM 2.6p1 which will include the full path of the .fconfig file in the debug log. Please create another debug log with that version. A "FOLDER" debug log should be sufficient, no need .

Okay. I have attached the serial log with this extended debug version.

Here is the actual path of the .fconfig file.
New Shell process 9
9.AmigaOS4:> list work:NetApps/YAM/incoming/.fconfig
Directory "work:NetApps/YAM/incoming" on Friday 20-Jan-12
.fconfig 355 ----rw-d Today 11:42:43
1 file - 355 bytes - 2 blocks used

From the log it seems yam is trying to open the same file.

Please attach your .folders file to this ticket and I need to know the MAILDIR ToolType of YAM's icon. I think there is something wrong with the pathes YAM has to work with. Did you change anything in this respect?

.folders file attached

The MAILDIR tool type is current disabled
(MAILDIR=YAM

This has not been changed recently, certainly not since I install 2.6p1

debug with @all,folder set

I've attached the debug output croped just after the section that loads incoming, as the log became exceptionally long, and in fact YAM never loaded.

I think the relevant info is shown though, for some reason YAM can't open the file and so writes a new one in it's place.

It seems strange as other programs do successfully open the file.

I tried an experiment where by I created a copy of the incoming directory, with COPY ALL CLONE, then renamed the original to incoming.bak and replaced it with the copy.

On starting YAM this time it loads normally, without overwriting the .fconfig file.

if I swap the directories back again then the error returns.

This makes me wonder if there is an issue with the incoming directory at the filesystem level although I see no other symptoms than YAM failing to open that .fconfig but only that particular .fonfig

My work: partition is using SFS/00

Replying to broadblues:

This makes me wonder if there is an issue with the incoming directory at the filesystem level although I see no other symptoms than YAM failing to open that .fconfig but only that particular .fonfig

My work: partition is using SFS/00

Well, since I am out of ideas and if cloning the folder and using the clone instead of the original cure the problem I suggest to continue to use the clone and delete the original folder. I am sure that YAM is innocent as the cloned folder works perfectly for you, you did not update YAM for a long time and I am unable to reproduce the issue. Maybe SFS's internal structures are really broken in a particular way. I really cannot tell why this happens.

If you are confident with this solution then just close this ticket as "works for me".

I've run through several cycles with the coppied incoming directory, and it's working fine, so I'll take the resolved worksforme option.