Code

Opened 8 years ago

Closed 6 years ago

#1194 closed enhancement (wontfix)

[patch] Check for file permissions for proper error messages

Reported by: Tim Owned by: nobody
Component: Core (Other) Version:
Severity: normal Keywords:
Cc: tbarta@… Triage Stage: Design decision needed
Has patch: yes Needs documentation: no
Needs tests: yes Patch needs improvement: no
Easy pickings: UI/UX:

Description

I'm not sure how possible it is, but sometimes the error messages (eg TemplateDoesNotExist) don't reflect the correct problem. I've had a few times where it was simply a case of the apache user not being able to read the files, but the error message meant that I was looking at the problem from the wrong persective.

Would this be hard / worthwhile to implement? Maybe even at a basic level it could tell the user in the error message to check permissions?

Attachments (1)

filesystem.diff (2.1 KB) - added by tbarta@… 7 years ago.
patch to generate a different exception type when a file is found but unreadable

Download all attachments as: .zip

Change History (4)

comment:1 Changed 7 years ago by SmileyChris

  • Triage Stage changed from Unreviewed to Design decision needed
  • Version 0.90 deleted

Changed 7 years ago by tbarta@…

patch to generate a different exception type when a file is found but unreadable

comment:2 Changed 7 years ago by tbarta@…

  • Cc tbarta@… added
  • Has patch set
  • Needs tests set
  • Summary changed from Check for file permissions for proper error messages to [patch] Check for file permissions for proper error messages

I don't know much about the template loading system, but this patch should generate a different exception if a file is found in the template path, but could not be read due to access permissions. The exception raised is a subclass of TemplateDoesNotExist, so try/except blocks elsewhere in the code should work. I am not sure about the errno module's cross-compatibility... does anyone know if this will work with Windows or OS X?

comment:3 Changed 6 years ago by jacob

  • Resolution set to wontfix
  • Status changed from new to closed

I think adding the extra exception just makes the code more cluttered -- this is a pretty easy problem to figure out and diagnose.

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.