Code

Opened 3 years ago

Closed 2 years ago

Last modified 2 years ago

#15636 closed Bug (needsinfo)

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

Reported by: drakaar Owned by: jezdez
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?

Attachments (0)

Change History (20)

comment:1 Changed 3 years ago by jezdez

  • Keywords blocker added; collectstatic, lowercase removed
  • milestone set to 1.3
  • Needs documentation unset
  • Needs tests unset
  • Patch needs improvement unset

comment:2 Changed 3 years ago by jezdez

  • Owner set to jezdez
  • Status changed from new to assigned

comment:3 Changed 3 years ago by jezdez

This seems related to #8593.

comment:4 Changed 3 years ago by jezdez

  • Keywords blocker removed
  • Resolution set to needsinfo
  • Status changed from assigned to closed

What kind of deployment do you use?

comment:5 Changed 3 years ago by drakaar

I use google app engine to deploy.

comment:6 Changed 3 years ago by jezdez

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

comment:7 Changed 3 years ago by jacob

  • milestone 1.3 deleted

Milestone 1.3 deleted

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

  • Easy pickings unset
  • Resolution needsinfo deleted
  • Severity set to Normal
  • Status changed from closed to reopened
  • Type set to 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 follow-up: Changed 2 years ago by 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?

comment:10 Changed 2 years ago by anonymous

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

comment:11 Changed 2 years ago by apollo13

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

comment:12 Changed 2 years ago by jezdez

  • Resolution set to needsinfo
  • Status changed from reopened to closed

Marking as needsinfo for now..

comment:13 in reply to: ↑ 9 Changed 2 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 2 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 follow-up: Changed 2 years ago by wooyek

  • Resolution needsinfo deleted
  • Status changed from closed to reopened
  • Type changed from Uncategorized to 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 in reply to: ↑ 15 Changed 2 years ago by anonymous

  • Resolution set to needsinfo
  • Status changed from reopened to 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?

Last edited 2 years ago by ramiro (previous) (diff)

comment:17 follow-up: Changed 2 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 2 years ago by ramiro

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 follow-up: Changed 2 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 2 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.

Add Comment

Modify Ticket

Change Properties
<Author field>
Action
as closed
as The resolution will be set. Next status will be 'closed'
The resolution will be deleted. Next status will be 'new'
Author


E-mail address and user name can be saved in the Preferences.

 
Note: See TracTickets for help on using tickets.