From icculus at icculus.org  Tue May  1 17:22:51 2012
From: icculus at icculus.org (Ryan C. Gordon)
Date: Tue, 01 May 2012 17:22:51 -0400
Subject: [physfs] Making PHYSFS_FILETYPE_* a bitmask
In-Reply-To: <1986461674.20120425173700@driftsolutions.com>
References: <1986461674.20120425173700@driftsolutions.com>
Message-ID: <4FA0542B.5000606@icculus.org>


> So in the case a symlink that points to a file filetype would be set to
> PHYSFS_FILETYPE_REGULAR|PHYSFS_FILETYPE_SYMLINK.

The original intention was to match what most OSes do: you get the entry 
from the filesystem, and if you want to resolve the symlink it reports, 
you have to do more filesystem accesses.

However: what do we set this to if the symlink is pointing to another 
symlink? If we resolve all the symlinks, what do we set this to if the 
final symlink points back to the first, causing an infinite loop? What 
do we set this to if it's not pointing to anything at all?

Granted, we don't offer a PHYSFS_readlink() API to report to the app 
what a symlink points to, and we probably should.

--ryan.


From indy at driftsolutions.com  Tue May  1 18:16:15 2012
From: indy at driftsolutions.com (Indy Sams)
Date: Tue, 1 May 2012 18:16:15 -0400
Subject: [physfs] Making PHYSFS_FILETYPE_* a bitmask
In-Reply-To: <4FA0542B.5000606@icculus.org>
References: <1986461674.20120425173700@driftsolutions.com>
	<4FA0542B.5000606@icculus.org>
Message-ID: <978642338.20120501181615@driftsolutions.com>

Hello Ryan,

	Probably a combination of the two would be good (filetype and PHYSFS_readlink). Either way they could get into an infinite loop if there is a symlink pointed to a symlink unfortunately.

	It looks like in the current Mercurial root the only archiver that actually will return PHYSFS_FILETYPE_SYMLINK is the ZIP archiver. The POSIX __PHYSFS_platformStat() uses lstat(), but doesn't check S_ISLNK() so it would be returning PHYSFS_FILETYPE_OTHER instead of PHYSFS_FILETYPE_SYMLINK currently (in theory, haven't tested it).

	At this point, my current thoughts would be (just for the simplicity of use for users):

	If you PHYSFS_stat() a symlink, it would do one of the following:
		1. If symlinks are disabled with PHYSFS_permitSymbolicLinks, returns error that the file doesn't exist. This matches the current PHYSFS_stat() documentation.
		2. Or, returns the information on the linked file (ie. an additional stat() after the lstat() with PHYSFS_FILETYPE_SYMLINK |'ed to the filetype).

	It seems like this would work well and be simple for people to use without having to worry much about symlinks if they don't need the nitty gritty.
	
Tuesday, May 1, 2012, 5:22:51 PM, you wrote:


>> So in the case a symlink that points to a file filetype would be set to
>> PHYSFS_FILETYPE_REGULAR|PHYSFS_FILETYPE_SYMLINK.

RCG> The original intention was to match what most OSes do: you get the entry 
RCG> from the filesystem, and if you want to resolve the symlink it reports, 
RCG> you have to do more filesystem accesses.

RCG> However: what do we set this to if the symlink is pointing to another 
RCG> symlink? If we resolve all the symlinks, what do we set this to if the 
RCG> final symlink points back to the first, causing an infinite loop? What 
RCG> do we set this to if it's not pointing to anything at all?

RCG> Granted, we don't offer a PHYSFS_readlink() API to report to the app 
RCG> what a symlink points to, and we probably should.

RCG> --ryan.

RCG> _______________________________________________
RCG> physfs mailing list
RCG> physfs at icculus.org
RCG> http://icculus.org/mailman/listinfo/physfs


Best regards,
 Indy Sams
 mailto:indy at driftsolutions.com