Can't attach script to object

[Lunarovich]

I'm using the Ubuntu distribution of Linux. Everytime I try to attach a script to an object via the editor, the script appears to be attached and I save the map. When I select another object and select the object in question again, there is no script attached anymore. Likewise, the runtime completely ignores the script.

[DerRidda]

I can't seem to reproduce this. A shot in the dark: What file system is the project you are trying to work with saved on?

[Lunarovich]

I've started a project in Windows and the project is on the NTFS partition. Other modifications do get saved.

 

EDIT: It's definitely a NTFS partition issue. Linux version of LE cannot handle it. On the ext4 partition, scripts get attached as expected.

[Josh]

I don't even know how file paths in separate drives work on Linux? That would be my guess, if you have multiple drives you are working with.

[DerRidda]

They work just like every other file path: It's mounted into the same tree:

 

For example: '/path/to/a/file'

 

Let's forget that partitions are a thing for a moment and call everything drive, you can substitute drive for partition in this example.

 

'/' is on your boot drive of course, let's call that drive1 for example while the 'path' folder of '/path' might be on drive2, the 'to' folder of '/path/to' might even be back on drive1 and the 'a' folder of '/path/to/a' might be an a different drive entirely like drive3. The file 'file' naturally must be on the last drive in that hierarchy.

 

 

Bottom line is: You usually do not need to care about what drive you on right now, it's completely transparent. The one thing that doesn't work is hardlinking across different partitions even.

 

The important thing with this issue is the file system: NTFS doesn't store permissions in a compatible way with the side effect of not being able to execute file on NTFS partitions and is not case sensitive, that alone is enough to throw a serious curve-ball your way.

 

So yes, anything more than read-only file storage isn't recommended to do with NTFS on Linux. Nice to cut down on redundant storage when using a dual boot, useless for working with.

My guess is that's the reason why OS X only ships a read-only NTFS driver, so you don't even get tempted to try stuff that wasn't meant to work.

[Lunarovich]

As what regards execution, from my experience, it's sometimes possible to execute a file on the NTFS partition and sometimes it's not. For example, I was able to run a LE game executable on an NTFS drive in Linux.

 

P.S. The reason I was using NTFS was having a dual boot. I needed to store files on the partition that's accessible both to Linux and Windows. An Ext4 partition is invisible, as if it was inexistant, in Windows.

[Wazubaba]

I've run into this issue myself on Debian Linux. One thing that seems to make this work is to manually navigate to the file's absolute path in the browser, i.e. /media/<yourDrive>/path/to/file

 

It seems to be related to cross-device symlinks.

 

I tend to keep all my work on an external HDD, which is partitioned as ntfs just so windows can read it with minimum hassle myself. There are tools to browse ext partitions, but they are slow and kind of a pain :/

[reepblue]

Huh, this maybe why I had trouble when I tried to run Linux on my main machine.

 

I think the best way I've found to cross-develop is to have 2 machines with the project on a git. Of-course, not everyone has 2 PCs, and the only need to cross-develop is if you're building applications for each OS.