Opened 6 years ago

Closed 5 years ago

Last modified 5 years ago

#15636 closed Bug (needsinfo)

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

Reported by: drakaar Owned by: Jannis Leidel
Component: contrib.staticfiles Version: master
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 Changed 6 years ago by Jannis Leidel

Keywords: blocker added; collectstatic lowercase removed
milestone: 1.3
Needs documentation: unset
Needs tests: unset
Patch needs improvement: unset

comment:2 Changed 6 years ago by Jannis Leidel

Owner: set to Jannis Leidel
Status: newassigned

comment:3 Changed 6 years ago by Jannis Leidel

This seems related to #8593.

comment:4 Changed 6 years ago by Jannis Leidel

Keywords: blocker removed
Resolution: needsinfo
Status: assignedclosed

What kind of deployment do you use?

comment:5 Changed 6 years ago by drakaar

I use google app engine to deploy.

comment:6 Changed 6 years ago by Jannis Leidel

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

comment:7 Changed 5 years ago by Jacob

milestone: 1.3

Milestone 1.3 deleted

comment:8 Changed 5 years ago by george.ma1982@…

Easy pickings: unset
Resolution: needsinfo
Severity: Normal
Status: closedreopened
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.

comment:9 Changed 5 years ago by 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?

comment:10 Changed 5 years ago by anonymous

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

comment:11 Changed 5 years ago by Florian Apolloner

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

comment:12 Changed 5 years ago by Jannis Leidel

Resolution: needsinfo
Status: reopenedclosed

Marking as needsinfo for now..

comment:13 in reply to:  9 Changed 5 years ago by 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.

comment:14 Changed 5 years ago by 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)

comment:15 Changed 5 years ago by wooyek

Resolution: needsinfo
Status: closedreopened
Type: UncategorizedBug

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 in reply to:  15 Changed 5 years ago by anonymous

Resolution: needsinfo
Status: reopenedclosed

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?

Last edited 5 years ago by Ramiro Morales (previous) (diff)

comment:17 Changed 5 years ago by wooyek

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

comment:18 in reply to:  17 Changed 5 years ago by 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?

comment:19 Changed 5 years ago by 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

comment:20 in reply to:  19 Changed 5 years ago by 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.

Note: See TracTickets for help on using tickets.
Back to Top