Re: [hatari-devel] Doing Hatari 2.6.1 release -> trailing / in directory

[Andreas Grabher <andreas_g86@xxxxxxxxxx>]

> Am 22.07.2025 um 10:07 schrieb Nicolas Pomarède <npomarede@xxxxxxxxxxxx>:
> 
> Le 21/07/2025 à 23:52, Andreas Grabher a écrit :
>> I don’t use gemdos.c, so I did not recognise that one. But good to see that the problem was known at some point. I still think that slashes should not be added at any point so we don’t have to remove them afterwards. I am not sure if File_CleanFileName() works correctly on Windows. It will change "C:\" to "C:". I am not sure that is valid on Windows?
> 
> By briefly looking at the code, I thought it would not remove a '\' if there's a ':' just before, but maybe I misread.
> 
> 

Starting at the end of the filename it will remove trailing separators until there are no more or the length of the filename is 2 or less (e.g. C:, /a, /):

void File_CleanFileName(char *pszFileName)
{
	int len;

	len = strlen(pszFileName);

	/* Remove end slashes from filename! But / remains! Doh! */
	while (len > 2 && pszFileName[--len] == PATHSEP)
		pszFileName[len] = '\0';
}

But maybe Windows accepts C: as a valid path.

>>> Am 21.07.2025 um 22:26 schrieb Nicolas Pomarède <npomarede@xxxxxxxxxxxx>:
>>> 
>>> Le 20/07/2025 à 09:13, Andreas Grabher a écrit :
>>>> It depends on what you do with the path string. The GUI itself will work for the most part (I think except for showing no directory icons; but the icons are meaningless anyway; probably should be redesigned to show files or folders). I have no machine for testing, so I am not sure about that.
>>>> Anyway as soon as you call stat() with one of the path strings it will fail. Is it really a good idea to keep this? This can cause very hard to debug issues in the future. stat() does not tell you what’s wrong (just reporting ENOENT). I only found the problem because I have been reading about trailing slashes some time before in a different context. I was lucky.
>>>> I don’t think it depends on the toolchain. I am using the same CMake files as Hatari does. The user reporting the issues is using MinGW for compilation. The Microsoft documentation that I linked to earlier is not specific to some special conditions. It seems to be a general issue.
>>> 
>>> Hi
>>> 
>>> I didn't work on this part, but I see these 2 functions :
>>> - File_AddSlashToEndFileName
>>> - File_CleanFileName
>>> 
>>> for example in gemdos.c / GemDOS_ChDir() :
>>> 
>>>        /* Remove trailing slashes (stat on Windows does not like that) */
>>>        File_CleanFileName(psTempDirPath);
>>> 
>>>        if (access(psTempDirPath, F_OK) != 0)
>>>        {
>>>                /* error */
>>>                free(psTempDirPath);
>>>                Regs[REG_D0] = GEMDOS_EPTHNF;
>>>                return true;
>>>        }
>>> 
>>>        File_AddSlashToEndFileName(psTempDirPath);
>>> 
>>> So, the problem of "stat" is already known and handled here. Maybe it needs to be added in other places too ?
>>> 
>>> 
>>> File_AddSlashToEndFileName() is also called from dlgFileSelect.c to add a trailing / (or \) to directory.
>>> 
>>> I don't know why it was made that way, adding a trailing '/' to dir name doesn't look useful at first sight, because later dir and file are concatened with things like "%s%c%s" with %c being PATHSEP.
>>> 
>>> I'd rather not touch this part of the code unless someone can explain why it was made that way.
>>> 
>>> Nicolas
>>> 
>>> 
>>> 
>>> 
>>>>> Am 20.07.2025 um 08:54 schrieb Thomas Huth <th.huth@xxxxxxxxx>:
>>>>> 
>>>>> Am Sat, 19 Jul 2025 22:46:38 +0200
>>>>> schrieb Andreas Grabher <andreas_g86@xxxxxxxxxx>:
>>>>> 
>>>>>> I really think the trailing backslash issue should be fixed.
>>>>> 
>>>>> We've got LFS support in Hatari since many years already, so I'm wondering
>>>>> why none of our Windows users has complained about this ever...?
>>>>> Maybe it's only related to your toolchain / Previous?
>>>>> 
>>>>>>> Am 19.07.2025 um 22:44 schrieb Nicolas Pomarède <npomarede@xxxxxxxxxxxx>:
>>>>>>> 
>>>>>>> Le 08/07/2025 à 19:01, Nicolas Pomarède a écrit :
>>>>>>>> Hi
>>>>>>>> seeing the few reports we got since releasing 2.6.0 and the fixes that were already done or are incoming, I think it could be possible do a 2.6.1 release soon, maybe before end of july.
>>>>>>>> So, let's not push big changes for the moment to the git repo, small new changes are possible, in order to limit possible new regression when we do 2.6.1
>>>>>>> 
>>>>>>> some changes were pushed already, any more pending stuff that could go into 2.6.1 ?
>>>>> 
>>>>> I've got nothing pending for 2.6.1 right now, so from my side, you can go
>>>>> ahead!
>>>>> 
>>>>> Thomas
>>>>> 
>>>>> 
>>> 
>>> 
>>> 
>