Truncated file served up from htdocs through symlink

[abudinsz@…]

I ran into an interesting problem yesterday while trying to add some static content in the htdocs folder. I added a couple of symlinks to some files that are really not that static in terms of content (nightly build logs and such). The size of the symlink when doing a ls -l is basically the length of the path you are pointing to; this is to be expected.

Here is an example of what I'm seeing:

[root@system /opt/trac/project/htdocs] ls -l test.*
-rw-r--r--    1 apache   apache         51 Dec  8 17:49 test.cfg

[root@system /opt/trac/project/htdocs] ln -s test.txt test.ln.txt

[root@system /opt/trac/project/htdocs] ls -l test.*
-rw-r--r--    1 apache   apache         51 Dec  8 17:49 test.txt
lrwxrwxrwx    1 apache   apache          8 Dec  9 11:03 test.ln.txt -> test.txt

Now if I use the following URL everything works (I get the full test.txt file):
http://trac/chrome/site/test.log

If on the other hand I use this URL then it is busted (I only get the first 8 bytes of test.txt):
http://trac/chrome/site/test.ln.log

I'm using Apache 2.0.46 to server up Trac 0.9

I actually tested using a longer file name (even a fully qualified path) and I actually got more data, always correlating with the symlink size. Even though htdocs is under my DocumentRoot I tried to force a FollowSymlinks option for the entire VirtualHost but to no avail. BTW if I take Trac out of the picture and serve up those files through my same VirtualHost directly then the symlinked URL works perfectly. So my guess is (from the name of the URL) that chrome may be munging something… when looking at the file system it doesn't use the right API to get the file size and it instead gets the symlink size.

[sid]

This seems to be outside the scope of Trac. You might be able to use the Include macro to accomplish this.. but no guarantees.

Propose a wontfix resolution to this ticket.

[Christian Boos]

Well, I thought this could have been a real issue:

chrome may be munging something… when looking at the file system it doesn't use the right API to get the file size and it instead gets the symlink size.

But in Request.send_file, we're using os.stat, which seems to do the right job for a symbolic link (at least with Python 2.4.2 on Linux).

However, I just tested, and it also doesn't work for me… Actually, the size is correct, as expected, but the content is truncated to the length of the link file. So the problem is in the reading, though it's not exactly clear why at this point (doing the steps manually seems to work).

(Also, I don't see how the Include macro would have helped here; the original request was more being able to simply link to local resources, see htdocs:).

[osimons]

With 0.11 and the very recent trac-admin copystatic command to get resources out of the egg into a location not managed by Trac (+ using [trac] htdocs_location), isn't this ticket irrelevant as no-one would really want to try to link new static files into the egg? (Unless someone actually wants to pick this up for 0.10.x, naturally.)

[Christian Boos]

The issue (if it's still there) is still relevant because of TracStandalone#Servingstaticcontent

[Christian Boos]

Can't reproduce anymore.