Re: Testing unexpected I/O failures

Not exactly sure what failure mode for reading you're trying to emulate. Are you checking with -r then if that succeeds doing the open? Because if so then that's introducing a possible race condition. In general it's better to do whatever open operation and deal with the failure than do a test and then take action (the former will be atomic; the latter opens a window something else can change the state of the filesystem under you).

That being said if that is what you're trying to emulate I want to say that I've seen weird access and permissions behavior when running as root on a filesystem with the squash root option on (then again I may be recalling something in Tcl where it was using the access(3) library routine which short circuited and always returned true for root).

The cake is a lie.
The cake is a lie.
The cake is a lie.

Comment on Re: Testing unexpected I/O failures Select or Download Code

Replies are listed 'Best First'.
Re^2: Testing unexpected I/O failures by kcott (Archbishop) on Nov 24, 2020 at 20:05 UTC
G'day Fletch, Overall, there are a lot of input parameters; currently, there are about 50 possible messages that can arise when the sanity checks are run. Most of these are not related to any file checks: "A can't be zero-length"; "B must be an integer"; "C can't be greater than D"; and so on. There are nine file-related checks as outlined in the OP. I wanted to get all sanity checks performed prior to starting the processing proper; which begins with `open`ing the input file. I considered it to be more useful to advise the user upfront that there was a specific problem with the directory or file parameter supplied, rather than offering a generic `$!` message from `open`, such as "File not found", "Permission denied", or similar. Your suggestion of doing the `open` first with supplied values (i.e. `dir_param/file_param`) and then dealing with failure might be a better way to go. Something like: `open ... or do { ... };` [download] With the `do` determining more specific messages: "Directory was not supplied"; "File specified does not exist"; and so on. If users get a specific message, it may indicate something they can fix themselves, especially if it's a simple typo; e.g. file parameter supplied as `file.tx` but should be `file.txt`. When presented with a generic message, users may not be able to investigate themselves and may, unfortunately, provide the oft seen error report: "It didn't work". — Ken	[reply] [d/l] [select]
Re^3: Testing unexpected I/O failures by Fletch (Bishop) on Nov 25, 2020 at 14:31 UTC
The idiom I've normally used is more along the lines of something like this; call `open` then use constants from Errno to figure out from `!$` what specifically went wrong and give more detailed advice. You can also use a variation on this to (e.g.) try and open a file for reading and fall back to another default location if `!$ == ENOENT` because it didn't exist; (EDIT) or you don't care if it didn't exist, but other errors you do want to bring to the user's attention. `use Errno qw( :POSIX ); use Log::Log4perl; ## ... if( open( my $fh, q{<}, $filename ) ) { my $frobulated_data = {}; ## process with $fh close( $fh ); return $frobulated_data; } else { if( $! == ENOENT ) { ERROR( qq{Couldn't find file '$filename': $!} ); } elsif( $! == EACCES ) { ERROR( qq{Problems with permissions for '$filename': $!} ); } elsif( ## whatever else specific you want to handle ... ) { #... } else { ERROR( qq{Problem opening '$filename': $!} ); } return; }` [download] The cake is a lie. The cake is a lie. The cake is a lie.	[reply] [d/l] [select]