symlink not supported ?

Questions about the LÖVE API, installing LÖVE and other support related questions go here.
Forum rules
Before you make a thread asking for help, read this.
User avatar
TsT
Party member
Posts: 161
Joined: Thu Sep 25, 2008 7:04 pm
Location: France
Contact:

symlink not supported ?

Post by TsT » Tue Apr 26, 2011 11:25 am

Hello,

I understand the symlink inside zip file (.love file) was not supported (and it's not my problem).
My problem went I'm running love for development like :

Code: Select all

love mydirectory/
symlink are reallly usefull to have a tree like :

Code: Select all

common/lib/ -- where every lua and love lib are available
project1/   -- a first love game project
    main.lua
    lib -> ../common/lib -- a symlink to access the lib without making copies

project2/   -- a second love game project
    main.lua
    lib -> ../common/lib -- a symlink to access the lib without mading copies
The love.filesystem.exists(), load(), enumerate() don't see my symlink files.
Is not supporting symlink is a choice or just a miss ?

Regards,
My projects current projects : dragoon-framework (includes lua-newmodule, lua-provide, lovemodular, , classcommons2, and more ...)

User avatar
bartbes
Sex machine
Posts: 4944
Joined: Fri Aug 29, 2008 10:35 am
Location: The Netherlands
Contact:

Re: symlink not supported ?

Post by bartbes » Tue Apr 26, 2011 1:15 pm

It's a default by the lib we use for love.filesystem, and we see no reason to set it to allow symlinks.

User avatar
Robin
The Omniscient
Posts: 6506
Joined: Fri Feb 20, 2009 4:29 pm
Location: The Netherlands
Contact:

Re: symlink not supported ?

Post by Robin » Tue Apr 26, 2011 1:56 pm

Maybe hardlinking is an alternative here?
Help us help you: attach a .love.

User avatar
TsT
Party member
Posts: 161
Joined: Thu Sep 25, 2008 7:04 pm
Location: France
Contact:

Re: symlink not supported ?

Post by TsT » Tue Apr 26, 2011 2:15 pm

bartbes wrote:It's a default by the lib we use for love.filesystem, and we see no reason to set it to allow symlinks.
And I don't understand why... symlink are so usefull !
Robin wrote:Maybe hardlinking is an alternative here?
Not really. hardlinking directories is not a good idea, and hardlinking every files are boring (and keeping synced are not automatic).
My projects current projects : dragoon-framework (includes lua-newmodule, lua-provide, lovemodular, , classcommons2, and more ...)

User avatar
bmelts
Party member
Posts: 380
Joined: Fri Jan 30, 2009 3:16 am
Location: Wiscönsin
Contact:

Re: symlink not supported ?

Post by bmelts » Tue Apr 26, 2011 6:38 pm

TsT wrote:And I don't understand why... symlink are so usefull !
Consider the following file structure:

Code: Select all

evil.love
    EvilSymlink -> ~
    EvilerSymlink -> /usr/local
Symlinking breaks sandboxing. Whether LÖVE should be sandboxed or not is another debate (boy is it ever), but as long as it is, symlinks are not acceptable.

User avatar
TsT
Party member
Posts: 161
Joined: Thu Sep 25, 2008 7:04 pm
Location: France
Contact:

Re: symlink not supported ?

Post by TsT » Tue Apr 26, 2011 9:56 pm

I need symlink for personnal development use. I build my own symlink and I don't be afraid of myself :ultraglee:

You speak about security and sandboxing ... when os.remove(), io.open and loadstring and are available ?

If we have a love.filesystem.isSymlink(file) and/or love.filesystem.getSymlinkTarget(file) (to get where the symlink is pointing to)
it should possible to check what you want really load or not.
And be able to filter this kind of files for people that want this !

I like security and sandboxing, I doing from scratch my old own security project for löve, love-master started in 2008.
But just now I guest be able to use symlink. I prefer be able to restrict dangerous features and be able to use it with take than nothing.

For now my workaround is to patch the love.filesystem.load() to check if love.filesystem.exists return false then trying directly with loadstring.

I guest having a love --insecure that allow every dangerous functions (usefull for developement) and running love by default without dangerous functions.
Am I wrong ?
My projects current projects : dragoon-framework (includes lua-newmodule, lua-provide, lovemodular, , classcommons2, and more ...)

User avatar
TechnoCat
Inner party member
Posts: 1611
Joined: Thu Jul 30, 2009 12:31 am
Location: Denver, CO
Contact:

Re: symlink not supported ?

Post by TechnoCat » Tue Apr 26, 2011 10:03 pm

TsT wrote:You speak about security and sandboxing ... when os.remove(), io.open and loadstring and are available ?
Shhhh!!! People can hear you!

User avatar
TsT
Party member
Posts: 161
Joined: Thu Sep 25, 2008 7:04 pm
Location: France
Contact:

Re: symlink not supported ?

Post by TsT » Tue Apr 26, 2011 10:27 pm

:rofl:

User avatar
BlackBulletIV
Inner party member
Posts: 1260
Joined: Wed Dec 29, 2010 8:19 pm
Location: Queensland, Australia
Contact:

Re: symlink not supported ?

Post by BlackBulletIV » Tue Apr 26, 2011 10:59 pm

Lol, yeah, using symlinks are the easier counter part of hacking around with os.execute and the io.* functions.

As for sandboxing, I personally think that folders and merged executables should have full rights, only to have their rights governed by the OS. This would make LOVE a good game development platform. But when it comes to a .love, sandboxing should be started; this makes LOVE a good game platform.

User avatar
bmelts
Party member
Posts: 380
Joined: Fri Jan 30, 2009 3:16 am
Location: Wiscönsin
Contact:

Re: symlink not supported ?

Post by bmelts » Wed Apr 27, 2011 4:00 am

BlackBulletIV wrote:As for sandboxing, I personally think that folders and merged executables should have full rights, only to have their rights governed by the OS. This would make LOVE a good game development platform. But when it comes to a .love, sandboxing should be started; this makes LOVE a good game platform.
*downloads sandboxed .love*
*merges .love into executable*
:joker:

Post Reply

Who is online

Users browsing this forum: Bing [Bot] and 5 guests