Bug#898483: Acknowledgement (failed creating configuration directroy: unsupported)

[James Cowgill]

Control: tags -1 - patch

Hi,

On 12/05/18 14:33, Lumin wrote:
> control: tag -1 +patch
> I think the problem lays in main.cpp :
> 
>    81     // Set configuration directory
>    82     //sprintf(writedir, "%s.%s", userdir, application);
>    83     sprintf(writedir, "%s%s", userdir, application);
>    84     if(!PHYSFS_setWriteDir(writedir)) {
>    85         // try to create the directory
>    86         char* mkdir = new char[strlen(application) + 2];
>    87         sprintf(mkdir, "%s", application);
>    88         if(!PHYSFS_setWriteDir(userdir) || !PHYSFS_mkdir(mkdir)) {
>    89             std::ostringstream msg;
>    90             msg << "Failed creating configuration directory '" <<
>    91                 writedir << "': " << PHYSFS_getLastError();
> 
> Looks like that the author forgot to concat the "userdir" and "mkdir"
> before really creating it. If that's where the root of problem lies,
> a possible fix could be:
> 
>     char* mkdir = new char[strlen(userdir) + strlen(application) + 2];
>     sprintf(mkdir, "%s%s", userdir, applicatoin);
>     if(!PHYSFS_setWriteDir(userdir) || !PHYSFS_mkdir(mkdir)) {
> 
> Not verified. Hope it helps.

The original code looks correct to me. PHYSFS_mkdir operates relative to
the current writeDir, so you shouldn't need to provide a full path
(assuming the second PHYSFS_setWriteDir succeeds).

I think this is a bug in libphysfs 3.0.1. It seems that in this version
(unlike 2.0.3), PHYSFS_setWriteDir has the side effect of creating an
empty file if the path it is given does not exist. This will later cause
PHYSFS_mkdir to fail even if it's given the right path.

This would also explain why this bug is not present in stretch.

James

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: OpenPGP digital signature
URL: <http://alioth-lists.debian.net/pipermail/pkg-games-devel/attachments/20180512/942ec005/attachment-0001.sig>