django.contrib.staticfiles - "collectstatic" makes all files names lowercase.

[drakaar]

The collectstatic command copies all files from the appropriate locations but makes every file name lower case (maybe using lower) somewhere.

I updated to contrib.statifiles to r.15782 and ran the command on my windows development box. When I tested the website there were not problems because windows is filename case agnostic. When I deployed this site to GAE the static resources were not found.

Compare:
​http://2af1a37e95c1-django-iui.columbia-3.appspot.com/static/iui/t/default/backButtonBrdr.png to
​http://2af1a37e95c1-django-iui.columbia-3.appspot.com/static/iui/t/default/backbuttonbrdr.png

You can see by visiting the iui site that most resources are camelCased.

Can contrib.staticfiles preserve filename case as well when copying?

[Jannis Leidel]

This seems related to #8593.

[Jannis Leidel]

What kind of deployment do you use?

[drakaar]

I use google app engine to deploy.

[Jannis Leidel]

Please describe the steps so I can reproduce the issue. Any detail helps to find the issue.

[Jacob]

Milestone 1.3 deleted

[george.ma1982@…]

I confirm that it's indeed an issue on Windows. Say you have a file called Abc.js and you run collectstatic command. When this file is copied over to the specified folder, it's renamed to abc.js. It only happens on Windows, not *nix. I don't think drakaar need to provide more detailed steps. Just try on Windows and the issue can be noticed.

[Jannis Leidel]

I can't reproduce this on Windows 7, so please provide a test case that shows the issue. Also, which version of Windows did you use, a case insensitive filesystem, which Python, which version of Django?

[anonymous]

I can't reproduce it on Win XP SP3 32bit

[Florian Apolloner]

Oh, that last anonymous coward was me, sry for that.

[Jannis Leidel]

Marking as needsinfo for now..

[anonymous]

Replying to jezdez:

I can't reproduce this on Windows 7, so please provide a test case that shows the issue. Also, which version of Windows did you use, a case insensitive filesystem, which Python, which version of Django?

My environment: Windows Vista Home Basic SP2 32 bit, Python 2.7.2, Django 1.3.1. All the file names are changed to lowercase after I run collectstatic.

[wooyek]

Same here.

Python 2.7.2 (default, Jun 12 2011, 15:08:59) [MSC v.1500 32 bit (Intel)]

Microsoft Windows [Wersja 6.1.7601] (Windows 7 x64)

[wooyek]

I do not think that it is os dependent.

FileSystemStorage.path method uses django.utils._os.safe_join function to join base with paths which in turn uses normcase.

[anonymous]

Replying to wooyek:

I do not think that it is os dependent.

FileSystemStorage.path method uses django.utils._os.safe_join function to join base with paths which in turn uses normcase.

safe_join() was fixed in this regard in r16267.

Rather than analisis of code what we need is what jezdez has already esked twice above: An autocontained minimal application+test case with models/code/instructions that fails in your enviromment. We've had one core dev, one trusted collaborator both in this ticket, and at least one more person in the IRC channel reporting that they can't reprofuce this also using Windows.

Reopen the ticket only if you can provide that or if you can fin the problem that escapes us so far and provide a detailed explanation/solution.

What would be useful too is if you can tell us: filesystems in the source and destination of the copy operation. Are they local filesystems? Whis of them? mapped drives? Using which protocol?

[wooyek]

Everything is done on one single machine, single disk. I'll try to provide a test case.

[Ramiro Morales]

Replying to wooyek:

Everything is done on one single machine, single disk. I'll try to provide a test case.

(the anonymous above was me from a cell phone)

Thanks, which fileystem? FAT? NTFS?

[wooyek]

Sorry, my bad. The trunk version has been already been corrected. I did not check the details of this ticket when I was looking for it. I was writing under an assumption that it was for 1.3.1 version (silly me).

Answering your question: NTFS.

Again sorry for code analysis instead of test case, there is a problem:
https://code.djangoproject.com/browser/django/branches/releases/1.3.X/django/utils/_os.py#L37

And here it is corrected:
https://code.djangoproject.com/browser/django/trunk/django/utils/_os.py#L42

If you still need a test case, I'll try to write one. All I did up till now is create a no-app project with one static file. But when I got to learning how to write test for django framework itself I found that the trunk version is OK.

The project is here: ​http://www.dropbox.pl/file.php?name=449D082A80C3D12C33FBDF5E67AC35AE

Poke me if the test case is still needed, but you'll have to give me some time find my way in the test for static files

[anonymous]

Replying to wooyek:

Sorry, my bad. The trunk version has been already been corrected. I did not check the details of this ticket when I was looking for it. I was writing under an assumption that it was for 1.3.1 version (silly me).

Thanks for this clarification.

So you are seeing 1.3.x and this was fixed in trunk afterwards the 1.3 release. Unfortunately, according to the ​backporting policy in effect this isn't going to be ported to 1.3.x. We are going to fix it only in trunk if it efefctively still exists there.

This leaves us with the report by user george.ma1982 that reopened this ticket on March 1 2012 but without specifying what Django release/revision he is using.

If he is able to give us that information and it results he is using trunk then we still need information from him how to reproduce this and the needsinfo closing-reason of this ticket is correct, if he reports he us using 1.3.x then we can change the closing reason to fixed.

In any case the closed status is correct.