Folder Exist / Create

Probably an elementary question?

I wish to determine whether a given folder exists (this having been specified in advance as a full path by a user as a character variable), when the folder may be there already and empty.

If not there I wish to create the empty folder with this name and it there is a problem in doing so (the drive is invalid for example) detect this and report the same.

I am aware of MKDIR@ as a 'DOS' version of this, but I assume that this would return an error if both the folder was there or the folder could not be created. Is there a more modern command please?

Many Thanks

Bill

Bill,

I don't know of a routine to detect the status of a directory. ATTACH@ provides some ability, but you would need to understand the error return possibilities, such as: not a valid directory name, does not exist, parent does not exist, or is not a directory (could be a file). Access rights (including read, write and create alternatives) will also effect this status.

What you could use is FILES@ and detect all entries in the parent directory that is expected to contain the directory you are looking for. I've found FILES@ to be a reliable routine to use. You could search all entries in the directory for the name you are looking for (allow for case) and determine it's status. It might not exist, or might not be a directory. Hopefully the parent directory is valid and accessible.

Also, with Windows 7 (in comparison to XP), different access rights have been applied to a number of directories where read but not write or create access is available. You need to be careful with interpreting the error condition when you try to create a directory or create a file in a directory. Opening a file for read only access can often be the only access available, or sometimes being able to write/append to a file but not being able to create a file. Even having sys-admin rights is sometimes not enough. I use to have .log or .ini files in c:\ or c:\windows, but this is very difficult with Win-7. Write a test program to just create a directiory and also test the ability to create files in the directory. You may be surprised by the restrictions that are applied.

Hope this helps,

John

Another thing to try is the routine FEXISTS@.

For John really. These access rights are really difficult to get round. I wrote a very simple program for students to use on University computers outside the University on a field course. Unfortunately, about every hour, the computers would check to see if they were on a specific part of the University network, and if not, they would lock up - in every case if the task was completed within the hour, that was OK, but otherwise all effort up to that point was thrown away. When that particular problem was fixed, technical support had made all local hard disk writing impossible.

In the end, of course, I learned that the yes response to 'do you want to save your data before exit' must not exit if something goes wrong with saving, such as not having permission to save in the selected place, and also that the file selector is actually a file [u:424c3bc1f6]name[/u:424c3bc1f6] selector!

Eddie

Not so easy then! and with a number of potential problems.

My feeling is that I should create the folder with MKDIR@ (and if it is there already this should cause no problems), create / copy a test file there and check that it is there with fexists - should mean folder is there (at that point in time) and that I have write access.

Many Thanks all for the suggestions.

Bill

Having thought about it a bit more, there are (at least) 2 routes to this.

1. If you are programming a console application, then you are stuck with MKDIR@ and things of that ilk. In the FTN77 library (available as a PDF on the Silverfrost website) between pages 27 and 46 there are a number of routines that might be helpful - examining properties of files, for example.

2. If you are using Clearwin, whenever you use the Windows file selector, you get a window that enables the user to browse the directory tree and select files: a right-click on a file or directory enables you to inspect its properties, and using the appropriate option (for saving a file) allows you to add folders. However, my comments earlier about this being a file [u:0aee248705]name[/u:0aee248705] selector still apply, as you can select any available name, regardless of whether you can do anything with it or not.

Having moved in a single step from a limited number of directories / subdirectories and saving files in the same subdirectory as the source code and executable to Clearwin, I realise that I missed out the important sequence in the development of ideas between 1 and 2 above.

Eddie

In the end I have concluded that the simplest way to test that a folder exists and that I have rights to write to it is to simply open and write to the folder a dummy file and trap any errors!

mkdir@ will return meaningfull info (code 183) if the folder is already there, Code 0 if it is able to create a new folder and Code 3 if not there and/or cannot create.

Creating a folder using MKDIR@ does require that the parent directory already exists (unlike the DOS MKDIR command) but there is an API createdirectory which could be used, or alternatively use multiple calls to MKDIR@ (messy).

Thanks again, Bill

Bill,

I may have made some mistakes when testing, but I found it tricky to create a file in C:\ or C:\WINDOWS. While it appeared to work for 'READONLY', being able to update the file also had problems. From memory, position='APPEND' also helped. One of the problems I experienced was that the programs I was running were developed on XP so they did not have a rigorous error testing of IOSTAT. If I did as I recomended and wrote a more rigourous error testing program, I might develop more confidence about the restrictions that apply. My solution is to store files in another location; c:\utils is a directory I use for all my programs and now log files. Also, I get warnings using Explorer that I can not copy files into c:\ or c:\windows, although if I ignore the warning and the copy happens. I seem to stumble past these errors. I even have administrator privileges! Just a learning curve for the new O/S. You can tell us how it all works with Windows 8 !!!

John