Skip Menu |

This queue is for tickets about the File-Temp CPAN distribution.

Report information
The Basics
Id: 123959
Status: resolved
Priority: 0/
Queue: File-Temp
People
Owner: Nobody in particular
Requestors: SREZIC [...] cpan.org
Cc:
AdminCc:
Bug Information
Severity: (no value)
Broken in: 0.2304
Fixed in: 0.2307-TRIAL

History Show all quoted text
  Thu Dec 28 11:57:19 2017 SREZIC [...] cpan.org - Ticket created
Subject: EXLOCK should default to false
Currently EXLOCK defaults to true, which may be suprising for File::Temp users developing on non-BSD platforms (where EXLOCK=>1 does nothing), and encounter unexpected failures when running on BSD systems (where EXLOCK=>1 sets a lock, and if the temporary file is used by a component also setting a lock (e.g. sqlite) then things fail or even hang). In the past I created numerous bug reports against various CPAN modules because of this --- here's a small excerpt: * https://rt.cpan.org/Ticket/Display.html?id=122766 * https://rt.cpan.org/Ticket/Display.html?id=120419 * https://rt.cpan.org/Ticket/Display.html?id=117875 * https://rt.cpan.org/Ticket/Display.html?id=76415 * https://rt.cpan.org/Ticket/Display.html?id=76418 Actually I don't see the benefits of EXLOCK here. Is it for extra security? It's about non-mandatory locking, so there's no security benefit (and if, what about non-BSD systems?). Is it about being able to set a lock in an atomic way? But temporary files are unique, so one does not have to deal with concurrent access. Is there a use case for EXLOCK here? My suggestion is to change the default to EXLOCK=>0. I don't expect any breakages on CPAN and elsewhere, just contrary --- CPAN modules which are broken on BSD systems would work again. Regards, Slaven
  Thu Dec 28 12:02:44 2017 SREZIC [...] cpan.org - Correspondence added
On 2017-12-28 11:57:19, SREZIC wrote: Show quoted text
> Currently EXLOCK defaults to true, which may be suprising for > File::Temp users developing on non-BSD platforms (where EXLOCK=>1 does > nothing), and encounter unexpected failures when running on BSD > systems (where EXLOCK=>1 sets a lock, and if the temporary file is > used by a component also setting a lock (e.g. sqlite) then things fail > or even hang). In the past I created numerous bug reports against > various CPAN modules because of this --- here's a small excerpt: > > * https://rt.cpan.org/Ticket/Display.html?id=122766 > * https://rt.cpan.org/Ticket/Display.html?id=120419 > * https://rt.cpan.org/Ticket/Display.html?id=117875 > * https://rt.cpan.org/Ticket/Display.html?id=76415 > * https://rt.cpan.org/Ticket/Display.html?id=76418 > > Actually I don't see the benefits of EXLOCK here. Is it for extra > security? It's about non-mandatory locking, so there's no security > benefit (and if, what about non-BSD systems?). Is it about being able > to set a lock in an atomic way? But temporary files are unique, so one > does not have to deal with concurrent access. Is there a use case for > EXLOCK here? > > My suggestion is to change the default to EXLOCK=>0. I don't expect > any breakages on CPAN and elsewhere, just contrary --- CPAN modules > which are broken on BSD systems would work again. >
→ https://github.com/Perl-Toolchain-Gang/File-Temp/pull/22
  Sun Jun 24 02:03:53 2018 SREZIC [...] cpan.org - Reference by ticket #125670 added
  Sun Jun 24 02:04:28 2018 SREZIC [...] cpan.org - Correspondence added
On 2017-12-28 11:57:19, SREZIC wrote: Show quoted text
> Currently EXLOCK defaults to true, which may be suprising for > File::Temp users developing on non-BSD platforms (where EXLOCK=>1 does > nothing), and encounter unexpected failures when running on BSD > systems (where EXLOCK=>1 sets a lock, and if the temporary file is > used by a component also setting a lock (e.g. sqlite) then things fail > or even hang). In the past I created numerous bug reports against > various CPAN modules because of this --- here's a small excerpt: > > * https://rt.cpan.org/Ticket/Display.html?id=122766 > * https://rt.cpan.org/Ticket/Display.html?id=120419 > * https://rt.cpan.org/Ticket/Display.html?id=117875 > * https://rt.cpan.org/Ticket/Display.html?id=76415 > * https://rt.cpan.org/Ticket/Display.html?id=76418 > > Actually I don't see the benefits of EXLOCK here. Is it for extra > security? It's about non-mandatory locking, so there's no security > benefit (and if, what about non-BSD systems?). Is it about being able > to set a lock in an atomic way? But temporary files are unique, so one > does not have to deal with concurrent access. Is there a use case for > EXLOCK here? > > My suggestion is to change the default to EXLOCK=>0. I don't expect > any breakages on CPAN and elsewhere, just contrary --- CPAN modules > which are broken on BSD systems would work again.
Another one: https://rt.cpan.org/Ticket/Display.html?id=120419
  Sun Jun 24 02:05:23 2018 SREZIC [...] cpan.org - Reference to ticket #122766 added
  Sun Jun 24 02:05:23 2018 SREZIC [...] cpan.org - Reference to ticket #120419 added
  Sun Jun 24 02:05:23 2018 SREZIC [...] cpan.org - Reference to ticket #117875 added
  Sun Jun 24 02:05:23 2018 SREZIC [...] cpan.org - Reference to ticket #76415 added
  Sun Jun 24 02:05:23 2018 SREZIC [...] cpan.org - Reference to ticket #76418 added
  Sun Jun 24 12:23:54 2018 ether [...] cpan.org - Correspondence added
Since this ticket was created I've acquired comaint on this distribution. There is currently an outstanding trial release (from the Oslo Toolchaim Summit) that I will release as stable, and then release this change as a new trial for evaluation. Thanks for poking the ticket!
  Sun Jun 24 12:23:55 2018 The RT System itself - Status changed from 'new' to 'open'
  Sun Jun 24 16:33:20 2018 ether [...] cpan.org - Correspondence added
thank you! I released your patch in 0.2307-TRIAL.
  Sun Jun 24 16:33:20 2018 ether [...] cpan.org - Status changed from 'open' to 'resolved'
  Sun Jun 24 21:44:24 2018 ether [...] cpan.org - Fixed in 0.2307-TRIAL added