From: Jeremy N. <jn....@le...> - 2016-03-31 01:32:30
|
Using: REXX-ooRexx_4.2.0(MT)_64-bit 6.04 22 Feb 2014 on a W8.1 system I stumbled across a problem recently where after redirecting the output of a command to a file in my user's temporary files folder, I was unable to read that file using code like: tfstream = .stream~new(tmpfile) cresults = tfstream~arrayin tfstream~close I'd been using those three lines of REXX for years; all that had changed was that the way I specified the temporary file happened this time to start with "%TEMP%\" whereas when the code had worked before I'd first read the value of the %TEMP% environment variable & built filenames containing the actual path to %TEMP%, so filenames looked something like: "C:\Users\myuserid\....". I don't know enough about using .stream to know how to find out why it was unable to open the files concerned... which - incidentally - were all created properly by the redirected command in question (which was processing WAV sound files). When I first had the problem I did run file-compares across lots of example files and they were all the same. I've written a test case that just uses: echo some text > thetempfile to create each test file, and then shows that when the filename starts with "%TEMP%" the BIFs SysIsFile() and SysFileExists() both fail to recognise that the file has been created, even though a Windows 'dir' command will list it. I assume that whatever these functions test is possibly the same thing as seems then to prevent the .stream stuff from opening(?) or reading the files. running the test code here I see open/read failures on the files that the BIFs think don't exist, and success on the ones they think do exist. The test exec tries to create two files in %TEMP%, one with a leafname that has spaces in it and one without - both fail when the BIFs test the file. It also creates a similar pair of files with an explicit C:\Users.... path, and another pair in an ordinary subdirectory of C:\. The problem only happens with the first pair, and it's clear that whether or not filenames have spaces in them doesn't matter. All six files do get created. There's no code in the test exec to create the destination directory for the last pair of files; the exec assumes that "C:\WFE" exists. There's also no code that deletes any of the test files because I needed to be able to check that their contents was right. I manually deleted each set of 6 files before rerunning the code. If anyone else tries the exec they will need to create C:\WFE manually (or change the code to use some other place), and delete the test files afterwards manually. Anyone who tries it will also see that some of the BIF calls wrap the filenames in double quotes (which I did not think was needed, but thought I should try). In the test code none of the calls where double quotes are present work (and I expect they are not meant to). The calls that work or fail in the unexpected manner all don't have double quotes around the filenames. I'm happy to raise a bug report, but I'd like someone else to try the test code first... It's accessible at: https://www.dropbox.com/s/xh1s5rnjtxygyjk/Weird%20tempfile%20error.rexp?dl=0 - oh! The .rexp extension is what I use to indicate execs that run under rexxpaws; you might need to change that. -- Jeremy Nicoll - my opinions are my own. |