VIM the editor

@All
As i say before grabbing the 7.1 version of VIM from os4depot , and there swap files deletes fine.

Then i grab 7.1 vesion of vim sources from https://ftp.nluug.nl/pub/vim/amiga/
and build them myself, and bah : deleting of swap files not works !

So or author of 7.1 port for aos4 do fix something in that terms, or, newer SDK/Compiler/whatever made a differences.

The files which is used for, just 2:

https://github.com/vim/vim/blob/master/src/fileio.c

and

https://github.com/vim/vim/blob/master/src/memfile.c

But what is puzzling me, is why 7.1 version from os4depot have it working, but my build from official sources are not..

As i say protection bits clears exactly on closing/exit , while you works with it, protection bits are fine.

Any help welcome as usual :)

I run 'snoopy' over 7.1 from os4depot which delete .swp files on exit, and 7.1 builded from original sources which not delete .swp files on exit.

There is results when i already open "bugreport.txt", and start to catch logs when press ":q!".

7.1. from os4depot with working delete:



And 7.1 builded from original sources by me and where deleting not works:



As i can see, at the end, when called SetProtection, for non working version if called with 0x0000000F , and after that delete fail.

And for working version, SetProtection is called with 0x00000002, and then Delete didn't fail.

Also for working version i see there ExamineFH() before SetProtection is called, while in non-working vesion, there is ExamineObject(). So maybe those functions reacts different somehow which cause different SetProtection bits ?

Maybe it's os_amiga.c in end:

https://github.com/vim/vim/blob/master/src/os_amiga.c

I see there some amigaos4 ifdefs, which maybe coming after 7.1 public release on os4depot.

One of ifdefs is AllocDosObject() instead of FileInfoBlock stuff, so maybe that one differes a bit ..

And it seems that SetProtection didn't called from vim's code per-se there. Its some other function indirectly call it (dunno what one through).

@kas1e

Good findings!

SetProtection is called indirectly (via mch_setperm) in several places in Vim.

The values $2 and $f are interesting. $2 is HSPARWD and $f is HSPA.

8 7 6 5 4 3 2 1 <- Bit number
h s p a r w e d <- corresponding protection flag

0 = flag set
1 = flag clear

@sTix
Quote:

Yeah, i checked all the places where mch_setperm called : its is fileio.c only.

So i purely commented them out for tests: no changes. SetProtection still called which mean its inderectly called not from Vim, but from other DOS functions (seems so). Maybe when Examine called (and wchich replaced automatically on ExamineObject on compiling stage or so), dunno. But as far as i can tell, commenting out all calls to mch_setperm didn't stop SetProtect being called when i exit from vim.

The only explains i have that 7.1 version from os4depot works there, are :

1. it was build over clib2 (i checked, its indeed clib2, not newlib version)
2. it was compiled with much older DOS sdk.

@sTix

Quote:

Only the owner rwed flags are reversed (0 = enabled, 1 = disabled), the hspa and group and other rwed flags are set the normal way (0 = disabled, 1 = enabled).

@salass00

Ah, then $f is really null, nix, nada.

@All

Ok ! Some good and intersting news related to that strange issue.

I build vim with clib2 (as done for 7.1 version on os4depot), and that bug disappear !

I.e. everything deletes on exit fine, and final SetProtection also 0x00000002 and not 0x0000000f as in case when build with Newlib.

Any ideas ?:)

It is probabaly os_amiga.c still, just as it works with clib2 as expected, and set some strange 0 to protection only with newlib (and what DOS function do it?), it is probabaly newlib/dos doing something nasty there ?

@kas1e

It's also called from f_setperm(..) in evalfunc.c.

@kas1e

Very nice!

@sTix
Quote:

I even test it all with 7.1 sources (not mui gui, etc), there is no f_setfperm was at this time. So it definately called from some other dos function when need it.

@kas1e

Ah, my bad. I was grep:in through 8.1.x sources.

@sTix
And builded latest 8.1 version with mui-gui over clib2 : backup files also deletes fine.

So something definatelly differs between how newlib and clib2 handle DOS functions probabaly..

If we don't want to spend time to understand what wrong when we build it with newlib, easy way can be just build it over clib2.

@kas1e

Yes, clib2 is a good idea.

Who's maintaining newlib?

@sTix
Quote:

Some Belgian company full of laywers, update to os from which is probabaly unpossible to get anymore, taking aside any new SDK on which no one work :) clib2 from other side is free, opensourced , and hosted on adtools page together with latest binutils and gcc ports.

It can be that it also not newlib itself guilty, but code done in "wrong" for newlib way or something ..

@kas1e

Quote:

Sounds like clib2 is the way to go ;)

@kas1e
The empty filepermissions bug occurs because of a bug with dup2().

If the original file descriptor is closed before the duplicated one then the back reference got lost somehow (I forget the fine details) and the file permission got cleared.

This was reported by me in BZ 9294 (found whilst porting perl) and is fixed in newlib 53.34

@broadblues
Its something else, because vim doesn't call dup2() anywhere (there is in code only one place, but its not used for amigaos builds, i tested it twice to be sure).

It has some plain dup() calls, but they all ifdefed via #HAVE_DUP, which is not enabled for amiga builds, so dup() also in no use.

Also i do all my tests on newlib.library 53.50 , so bug definately not in dup2() and happens even on latest beta builds.

I retest also your test-case code from BZ 9294, and it indeed works with 53.50, so it mean that its another scenario of the same bug.

What functions of dos (or of newlib?) call SetProtection as well inderectly ? I mean, it can be bug just in Examine() in newlib, if it call SetProtection by itself. Or, it can be bug with SetCurrentDir or something which is called before that SetProtection bug happens based with above snoopy logs.

@pvanni, walkero & all

Uploaded new version of vim_mui to os4depot: which rebuilded now with clib2 instead of newlib, as newlib still have a bug with file permission got cleared, which in end lead to non-deleted swap files in VIM. clib2 will be used until fixed version of newlib will be publicaly available, or we will add workoround to VIM's code.

In other words, swap file deletion on exit/close will works now.

@kas1e,
great work, many thanks to you and to sTix

@kas1e,
wow, now all work very well, swap files and even persistent undo