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

[ Thread Index | Date Index | More lists.tuxfamily.org/hatari-devel Archives ]


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?


> 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
>>> 
>>> 
> 
> 
> 




Mail converted by MHonArc 2.6.19+ http://listengine.tuxfamily.org/