#15636 closed Bug (needsinfo)
django.contrib.staticfiles - "collectstatic" makes all files names lowercase.
Reported by: | drakaar | Owned by: | Jannis Leidel |
---|---|---|---|
Component: | contrib.staticfiles | Version: | dev |
Severity: | Normal | Keywords: | |
Cc: | Triage Stage: | Unreviewed | |
Has patch: | no | Needs documentation: | no |
Needs tests: | no | Patch needs improvement: | no |
Easy pickings: | no | UI/UX: | no |
Description
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?
Change History (20)
comment:1 by , 14 years ago
Keywords: | blocker added; collectstatic lowercase removed |
---|---|
milestone: | → 1.3 |
comment:2 by , 14 years ago
Owner: | set to |
---|---|
Status: | new → assigned |
comment:3 by , 14 years ago
comment:4 by , 14 years ago
Keywords: | blocker removed |
---|---|
Resolution: | → needsinfo |
Status: | assigned → closed |
What kind of deployment do you use?
comment:6 by , 14 years ago
Please describe the steps so I can reproduce the issue. Any detail helps to find the issue.
comment:8 by , 13 years ago
Easy pickings: | unset |
---|---|
Resolution: | needsinfo |
Severity: | → Normal |
Status: | closed → reopened |
Type: | → Uncategorized |
UI/UX: | unset |
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.
follow-up: 13 comment:9 by , 13 years ago
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?
comment:12 by , 13 years ago
Resolution: | → needsinfo |
---|---|
Status: | reopened → closed |
Marking as needsinfo for now..
comment:13 by , 13 years ago
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.
comment:14 by , 13 years ago
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)
follow-up: 16 comment:15 by , 13 years ago
Resolution: | needsinfo |
---|---|
Status: | closed → reopened |
Type: | Uncategorized → Bug |
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.
comment:16 by , 13 years ago
Resolution: | → needsinfo |
---|---|
Status: | reopened → closed |
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 asked for twice above: An autocontained minimal application+test case with models/code/instructions that fails in your environment. 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 find 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? Which of them? mapped drives? Using which protocol?
follow-up: 18 comment:17 by , 13 years ago
Everything is done on one single machine, single disk. I'll try to provide a test case.
comment:18 by , 13 years ago
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?
follow-up: 20 comment:19 by , 13 years ago
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
comment:20 by , 13 years ago
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.
This seems related to #8593.