Skip Menu |

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

Report information
The Basics
Id: 132064
Status: resolved
Priority: 0/
Queue: File-Slurp
People
Owner: cwhitener [...] gmail.com
Requestors: SVW [...] cpan.org
Cc:
AdminCc:
Bug Information
Severity: Important
Broken in: (no value)
Fixed in: (no value)

History Show all quoted text
  Thu Mar 05 11:19:31 2020 SVW [...] cpan.org - Ticket created
Subject: how to manipulate "tempXXXXX" if atomic option is true
File::Slurp version 9999.29 We wanted to use write_file() to atomically create a file inside a directory. Unfortunately the directory is observed by another daemon process that detects the intermediate "tempXXXXX" file. The daemon process would ignore hidden files for example. Could we change the behaviour in the following way: If the atomic option is true and if the option values contains at least 5 X characters (for example { atmoic => ".tempXXXXX" }) then the option value should be passed as is to 284: (undef, $file_name) = tempfile($opts->{atomic}, DIR => $dir, OPEN => 0); }
  Thu Mar 05 11:45:32 2020 ether [...] cpan.org - Correspondence added
On 2020-03-05 08:19:31, SVW wrote: Show quoted text
> File::Slurp version 9999.29 > > We wanted to use write_file() to atomically create a file inside a > directory. Unfortunately the directory is observed by another daemon > process that detects the intermediate "tempXXXXX" file. The daemon > process would ignore hidden files for example. Could we change the > behaviour in the following way: > > If the atomic option is true and if the option values contains at > least 5 X characters (for example { atmoic => ".tempXXXXX" }) then the > option value should be passed as is to > > > 284: (undef, $file_name) = tempfile($opts->{atomic}, DIR => $dir, OPEN > => 0); > }
I would suggest creating the file in a tempdir and then renaming it to the intended location afterwards.
  Thu Mar 05 11:45:32 2020 The RT System itself - Status changed from 'new' to 'open'
  Fri Mar 06 02:26:16 2020 SVW [...] cpan.org - Correspondence added
Am Do 05. Mär 2020, 11:45:32, ETHER schrieb: Show quoted text
> On 2020-03-05 08:19:31, SVW wrote:
> > File::Slurp version 9999.29 > > > > We wanted to use write_file() to atomically create a file inside a > > directory. Unfortunately the directory is observed by another daemon > > process that detects the intermediate "tempXXXXX" file. The daemon > > process would ignore hidden files for example. Could we change the > > behaviour in the following way: > > > > If the atomic option is true and if the option values contains at > > least 5 X characters (for example { atmoic => ".tempXXXXX" }) then > > the > > option value should be passed as is to > > > > > > 284: (undef, $file_name) = tempfile($opts->{atomic}, DIR => $dir, > > OPEN > > => 0); > > }
> > > I would suggest creating the file in a tempdir and then renaming it to > the intended location afterwards.
How to work around this missing File::Slurp::write_file() feature is known to us. This leads to additional code complexity and extra testing effort. I would appreciate and accept any decision about the validity of this feature request. Please close the ticket, if the request is rejected.
  Fri Mar 06 11:46:49 2020 ether [...] cpan.org - Correspondence added
On 2020-03-05 23:26:16, SVW wrote: n afterwards. Show quoted text
> > How to work around this missing File::Slurp::write_file() feature is > known to us. This leads to additional code complexity and extra > testing effort. I would appreciate and accept any decision about the > validity of this feature request. Please close the ticket, if the > request is rejected.
I am not a maintainer of this distribution so I cannot speak to that. I do know that all users are being actively encouraged to switch to other solutions (due to underlying issues that fundamentally cannot be solved), notably File::Slurper or Path::Tiny.
  Fri Mar 06 14:58:35 2020 cwhitener [...] gmail.com - Taken
  Fri Mar 06 15:12:07 2020 cwhitener [...] gmail.com - Correspondence added
Hi Everyone, Part of the reason that it's writing to the same directory as the resultant file is due to some potential issues of different directories having differing ACLs on them. If that case happens, the resultant file will end up with different permissions. There are a few other caveats there as well. Given those caveats, I'm not sure what that would look like. Adding another option or two there might be necessary to give the user the ability to override the default behavior: { atomic => 1, atomic_temp_pattern => 'tempXXXXX', atomic_temp_dir => '/foo/bar', } Then that gets a bit more to code around in an already complex function. On the other hand, making it a "hidden" temporary file all the time could be a solution by changing the temp file pattern to '.tempXXXXX' by default. This wouldn't add any complexity, would be a one character diff in the release and would solve your particular problem without changing behavior for the rest of the world. Is the latter a viable option that everyone would be happy with? Thanks, Chase
  Mon Mar 09 04:37:49 2020 SVW [...] cpan.org - Correspondence added
Am Fr 06. Mär 2020, 15:12:07, CAPOEIRAB schrieb: Show quoted text
> Hi Everyone, > > Part of the reason that it's writing to the same directory as the > resultant file is due to some potential issues of different > directories having differing ACLs on them. If that case happens, the > resultant file will end up with different permissions. There are a few > other caveats there as well. > > Given those caveats, I'm not sure what that would look like. Adding > another option or two there might be necessary to give the user the > ability to override the default behavior: > > { atomic => 1, atomic_temp_pattern => 'tempXXXXX', atomic_temp_dir => > '/foo/bar', } > > Then that gets a bit more to code around in an already complex > function. > > On the other hand, making it a "hidden" temporary file all the time > could be a solution by changing the temp file pattern to '.tempXXXXX' > by default. This wouldn't add any complexity, would be a one character > diff in the release and would solve your particular problem without > changing behavior for the rest of the world. > > Is the latter a viable option that everyone would be happy with? > > Thanks, > Chase
We are happy with your "one character diff" solution proposal. Please create a new release as soon as possible. Thanks, Sven
  Mon Mar 09 10:34:36 2020 cwhitener [...] gmail.com - Correspondence added
Hi Everyone, A release has been cut with the suggested change: https://metacpan.org/release/CAPOEIRAB/File-Slurp-9999.30 Thanks, Chase
  Mon Mar 09 10:34:37 2020 cwhitener [...] gmail.com - Status changed from 'open' to 'resolved'