VFP command to rename a directory?

[dmusicant]

I've written code to rename files, but have a situation where I have the names of directories in a table along with character data I'd like to use as new names for those directories. I'm hoping I can automate the process. Of course, this would entail a command to change the name of a directory. Is this possible?

 

[Olaf Doschke]

Well, there only is MKDIR and RMDIR to make the new directory and delete the old one. In between you'd need to move files.

That should be much easier using Scripting.Filesystemobject.

LOCAL loFS
loFS = CreateObject("scripting.filesystemobject")
lFSo.MoveFolder("c:\sourcefolder\","c:\destfolder\")

Bye, Olaf.

 

[Mike Lewis]

Alternatively, shell out to DOS and use the RENAME command. Note the syntax:

RENAME C:\OldDirectory NewDirectory

For the target name, just give the actual directory name, not the entire path.

Mike

__________________________________
Mike Lewis (Edinburgh, Scotland)

Visual FoxPro articles, tips and downloads

 

[Olaf Doschke]

By the way, moving folders or files is uch faster useing windows API methods anyway, as moving really just changes the file table of the file system and does not need to rewrite files, as long as both locations are on the same partition.

DECLARE INTEGER MoveFile IN kernel32;
        STRING lpExistingFileName, STRING lpNewFileName
MoveFile("c:\sourcefolder\","c:\destfolder\")

MoveFile also works on directories, as per description:

http://msdn.microsoft.com/en-us/library/windows/desktop/aa365239(v=vs.85).aspx

One word about using such things as scripting.filesystem or API functions: You have a dependency to an external component, these two exist in a wide range of Windows versions, so they are not a problem. Other API functions only exist since Vista or vice versa have deprecated in earlier Windows versions.

Bye, Olaf.

 

[dmusicant]

I decided it's more trouble than it's worth to try to automate the process. There are a few dozens of directories to be renamed, maybe a couple hundred at most. The directory names are such that they are hard to distinguish, is the worst of the problem. They are such as:

000510273400120
000510273410101
000510273860120
000510274140122
000510274141122
000510274150120
000510276540122
000510276541120

I've developed a workaround, being to place a text file in each directory named after and containing the new name, once it's time to make the change. It should prevent me from making mistakes.

Thanks for the replies!

 

[Olaf Doschke]

Why? What's the trouble doing it in code? One line per rename is too much? How about a loop?

As you say you have the old and new names in data it wouldn't matter how similar the names are, would it?

LOCAL loFS
loFS = CreateObject("scripting.filesystemobject")
scan yourdata
  If directory(alltrim(yourdata.oldfolder)) and !directory(alltrim(yourdata.newfolder))
     loFS.MoveFolder(alltrim(yourdata.oldfolder),alltrim(yourdata.newfolder)) 
  Endif
endscan

Just ensure you have fullpaths in yourdata. If not, add the base path, eg

#Define ccBasePath "C:\Basepath\"
LOCAL loFS
loFS = CreateObject("scripting.filesystemobject")
scan yourdata
  If directory(ccBasePath+alltrim(yourdata.oldfolder)) and !directory(ccBasePath+alltrim(yourdata.newfolder))
     loFS.MoveFolder(ccBasePath+alltrim(yourdata.oldfolder),ccBasePath+alltrim(yourdata.newfolder)) 
  Endif
endscan

Are you sure manually doing it is faster or simpler or less error prone? Any of these at least?

Bye, Olaf.

 

[Olaf Doschke]

Well,

of course it's

...
USE yourdata && at least SELECT yourdata, if the table is already opened
SCAN
...
ENDSCAN

Earlier on I had a typo lFSo instead of loFS. Was that hindering you to take that code? I still don't get, why two lines of code to rename a directory are too complicated.

Bye, Olaf.

 

[Mike Lewis]

Why? What's the trouble doing it in code? One line per rename is too much? How about a loop?

That was my thought as well.

If I was doing this, I would first get the directory names into a text file, which is easy, for example using the DOS DIR command, piping the output to a file. From there, it's a trivial step to create a cursor containing the directory names. Then write a small VFP program to loop through the cursor, renaming each one in turn.

But each to his own taste. If you are happy with the solution you adopted, that's fine.

Mike



__________________________________
Mike Lewis (Edinburgh, Scotland)

Visual FoxPro articles, tips and downloads

 

[dmusicant]

OK, you guys have inspired me to work out the automatic solution, although I've already placed those text files. I am not in the habit of using the Createobject command. I studied OOP in VFP, have supported and programmed in OOP VFP, but when I write code for myself I haven't used the Createobject command. I first studied FPD, then FPW....

 

[Mike Lewis]

Olaf's original suggestion (in the second post in this thread) was a good one. But don't discount my idea of using the DOS RENAME command. It has the benefit of being very simple.

On reflection, I think I might choose a slightly different approach to automating the solution:

1. Get the directory names into a text file (as before).

2. Open the file in a decent text editor (the VFP editor will be fine).

3. Using the editor's find/replace or macro features, convert each line of text from a plain directory name to a DOS RENAME command (my favourite way of doing that would be with VFP's macro feature, but that's only one of many approaches).

4. Rename the file so that it has a BAT extension.

5. Run it from the command prompt as a batch file.

This might not be to everyone's taste, but it would work, and would be fairly easy.

Mike

__________________________________
Mike Lewis (Edinburgh, Scotland)

Visual FoxPro articles, tips and downloads

 

[Olaf Doschke]

CreateObject is nothing to be afraid of, you're just using a class with it, bringing it to life. In the case of the scripting.filesystemobject you are using an OLE class. It has the MoveFolder method. And since that has no prerequisites of initialising any object properties or such, it's quite like a function call to a MoveFolder() function. It's just not standing alone, but a member of a class/object.

The DECLARE of the MoveFile function rather is like a SET PROCEDURE and not defining but enabling the use of a function of a DLL, the kernel32.dll, instead of using a function of the VFP language, which is a function of the vfp9r.dll. Anyway it's quite the same, despite you won't have to DECLARE any VFP function as it's integral part of the VFP language. But even though I warned about API usage, MoveFile is one of the very old and still not deprecated file system functions that's been there this way since maybe even before win95 and still existing in Windows 8. It's very safe to use. The more so, as you only need to use it once.

Bye, Olaf.