Im using ET on my linux box and with all the downloaded maps I have, its taking up a fair old chunk of hard-drive space.
What I was wondering was whether I could burn the downloaded maps onto CD and use symlinks in the etmain directory or would PB / ET get upset and not allow this?
Any help is appreciated 
That should work without any trouble. PB shouldn’t care one way or the other, and as long as ET can read them to calculate the checksum, it should be happy as well.
Ahh, I see. I was just thinking that PB might try to calculate the checksum on the symlink file rather than the actual file. I guess its down to how the filesystem is handled.
Cheers! Should save some space! :drink:
FWIW, on any POSIX-complaint OS, you have to explicitly say you want to read the link itself (e.g. call readlink or lstat.) Symbolic links are transparent to normal filesystem calls.
At any rate, PB seems to be having enough trouble checksumming itself, let alone anything else. :eek2:
Brings up old post
I have my NTFS volumes mounted and am using: “ln -s /windows/F/Program Files/et/etmain/mapfile.pk3” to symlink the files in my .etwolf dir.
The problem is that it sees the checksums as wrong and makes me redownload the maps.
Is it not possible to symlink succesfully over an NTFS mount?
It should be possible, but the NTFS code is very rough around the edges, so maybe something slightly different is being read for those pk3s. I’m not sure.
The only other thing that immediately comes to mind is to make sure you can read that pk3 file as the user you run ET as–the default permissions may only allow root to read files on your NTFS volume.
Well, if the server directs the client to download the map, then obviously the server is running. Ergo, it must have been able to read the .pk3 file, which means the problem is probably caused by something else. What that might be… not a clue, unfortunately.
Well, if the server directs the client to download the map, then obviously the server is running. Ergo, it must have been able to read the .pk3 file, which means the problem is probably caused by something else. What that might be… not a clue, unfortunately.[/quote]
I got the impression that he wasn’t running the server himself, which is why I suggested that he might not be able to read the pk3 at all.