It's not so simple. That test works as expected on Linux, it looks like it is only failing on Darwin.
Rick On Sat, Feb 16, 2019 at 6:38 AM Enrico Sorichetti via Oorexx-devel < oorexx-devel@lists.sourceforge.net> wrote: > Certainly different from windows , > > On unix it behaves according to the docs > > deleteFile uses unlink which does not check the permissions on the file > > E > > Quoting the libc manual > > > 14.6 Deleting Files > > You can delete a file with unlink or remove. > > Deletion actually deletes a file name. If this is the file’s only name, > then the file is deleted as well. If the file has other remaining names > (see Hard Links > <https://www.gnu.org/software/libc/manual/html_node/Hard-Links.html#Hard-Links>), > it remains accessible under those names. > Function: *int* *unlink* *(const char *filename)* > > Preliminary: | MT-Safe | AS-Safe | AC-Safe | See POSIX Safety Concepts > <https://www.gnu.org/software/libc/manual/html_node/POSIX-Safety-Concepts.html#POSIX-Safety-Concepts> > . > > The unlink function deletes the file name filename. If this is a file’s > sole name, the file itself is also deleted. (Actually, if any process has > the file open when this happens, deletion is postponed until all processes > have closed the file.) > > The function unlink is declared in the header file unistd.h. > > This function returns 0 on successful completion, and -1 on error. In > addition to the usual file name errors (see File Name Errors > <https://www.gnu.org/software/libc/manual/html_node/File-Name-Errors.html#File-Name-Errors>), > the following errno error conditions are defined for this function: > EACCES > > Write permission is denied for the directory from which the file is to be > removed, or the directory has the sticky bit set and you do not own the > file. > EBUSY > > This error indicates that the file is being used by the system in such a > way that it can’t be unlinked. For example, you might see this error if the > file name specifies the root directory or a mount point for a file system. > ENOENT > > The file name to be deleted doesn’t exist. > EPERM > > On some systems unlink cannot be used to delete the name of a directory, > or at least can only be used this way by a privileged user. To avoid such > problems, use rmdir to delete directories. (On GNU/Linux and GNU/Hurd > systems unlink can never delete the name of a directory.) > EROFS > > The directory containing the file name to be deleted is on a read-only > file system and can’t be modified. > > 11.2.3 File Name Errors > > Functions that accept file name arguments usually detect these errno error > conditions relating to the file name syntax or trouble finding the named > file. These errors are referred to throughout this manual as the *usual > file name errors*. > EACCES > > The process does not have search permission for a directory component of > the file name. > ENAMETOOLONG > > This error is used when either the total length of a file name is greater > than PATH_MAX, or when an individual file name component has a length > greater than NAME_MAX. See Limits for Files > <https://www.gnu.org/software/libc/manual/html_node/Limits-for-Files.html#Limits-for-Files> > . > > On GNU/Hurd systems, there is no imposed limit on overall file name > length, but some file systems may place limits on the length of a component. > ENOENT > > This error is reported when a file referenced as a directory component in > the file name doesn’t exist, or when a component is a symbolic link whose > target file does not exist. See Symbolic Links > <https://www.gnu.org/software/libc/manual/html_node/Symbolic-Links.html#Symbolic-Links> > . > ENOTDIR > > A file that is referenced as a directory component in the file name > exists, but it isn’t a directory. > ELOOP > > Too many symbolic links were resolved while trying to look up the file > name. The system has an arbitrary limit on the number of symbolic links > that may be resolved in looking up a single file name, as a primitive way > to detect loops. See Symbolic Links > <https://www.gnu.org/software/libc/manual/html_node/Symbolic-Links.html#Symbolic-Links> > . > > > > > On 16 Feb 2019, at 11:44, Rick McGuire <object.r...@gmail.com> wrote: > > No, those are correct. The test is expecting that an attempt to delete a > read-only file will fail. Just another one of those maddening differences > between platforms. > > > _______________________________________________ > Oorexx-devel mailing list > Oorexx-devel@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/oorexx-devel >
_______________________________________________ Oorexx-devel mailing list Oorexx-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/oorexx-devel
