Ticket #1801 (closed defect: fixed)

Opened 3 years ago

Last modified 2 years ago

DiskFile: two issues on file name

Reported by: gracinet Assigned to: fguillaume
Priority: P2 Milestone: CPS 3.4.4
Component: CPSSchemas Version: TRUNK
Severity: major Keywords: DIskfile integrity
Cc:

Description

  • In case the suggested id is already present on FS, getNewFileName() simply appends a number to it. Therefore it breaks the 'extension' part of the filename, e.g. 'bigmovie.avi' can turn into 'bigmovie.avi1'. Sadly, this breaks some content analysers, such as kaa.metadata.
  • a potential flaw: the reserved file name is computed during object instantiation and used at transaction commit time, when it might not be free anymore.

Shall I go ahead and fix this ?

Change History

12/27/06 19:25:10 changed by fguillaume

Be my guest :)

12/28/06 17:27:45 changed by gracinet

  • status changed from new to closed.
  • resolution set to fixed.

There was much more work needed than I expected :-( [50732] Hence this is a bit dangerous, esp. since unit tests don't test ZODB integration (did some browser functional testing)

See #1802 for further unrelated problems.

03/11/07 19:01:29 changed by gracinet

  • status changed from closed to reopened.
  • resolution deleted.
  • severity changed from normal to major.

Made a big mistake here, sorry: the filename is set on object after ZODB write, according, ironically, to my own comment. Therefore forthcoming transactions will always access the first file of that name. I've seen this happen in the wild.

03/12/07 10:25:55 changed by gracinet

  • status changed from reopened to closed.
  • resolution set to fixed.

Fixed in [51321] str madness stopped in [51322] (used to badly bug terminal in debug log level)