File & Folder Names Functions - Back to Basics

Some clarification as to descriptions I use:

• FullName = Path + FileName (Includes Drive + FileExt if present) (e.g. C:\path\filename.ext)
• Path = Folder path only (Including Drive). Should not include FileName. May or may not end with a PathSeparator (e.g. C:\path\ or C:\path )
• FileName = Name of file (Includes FileExt if present). Should not include Path (e.g. filename.ext)

Lately I've been pondering extracting information from file & folder names.

We already know how to do this!

Are you certain about that?


Here's a test - how do you write a function to return the file path from a FullName string?



I am guessing that most would answer something like this:

Please Login or Register  to view this content.

But what if someone passes a Path instead of a FullName argument?

Our function could fail. (e.g. "C:\path1\path2" would return as "C:\path1\" - we would lose part of the folder path without realising)


So I've felt the need to rethink the basics of any procedures that deal with file/folder names.

I want the functions to avoid returning incorrect results - as far as possible - regardless of whether the input is a fullname / filepath / filename

(e.g. a function for returning folder path should return an empty string where the input was a filename)


At this point, someone will say "why don't you validate the file/folder existence with Dir or FSO"?

But that won't work if you are dealing with a worksheet range listing files and/or folders from another PC.


So after some tinkering, below is as far as I can reach. If anyone can think of a way to tighten these functions, I'd be interested!

Please Login or Register  to view this content.

UPDATE:
I could alter the fnstrGetPathFromFullName procedure so that it checks for a file extension seperator - similar to what I did in fnstrGetFileNameFromFullName
But it would still fail on filenames that lack extensions

FAIL to any who used anything relying on InStr!

Aside from that it's InStrRev, not InStr, fail because ...?

Originally Posted by shg

Aside from that it's InStrRev, not InStr, fail because ...?

Well I wanted to pick a beginner mistake to lighten the mood before getting down to the heart of the matter. I agree that I should have picked a better example. It could slightly derail the thread so I have removed this from the OP.

Given that you can't tell the difference between a path and a filename without extension, what's the point? Also, you can use '.' in a folder name. In short, your goal is not achievable, but don't let that stop you.

Originally Posted by romperstomper

Given that you can't tell the difference between a path and a filename without extension, what's the point?

I'm not THAT crazy! I had already thought of that.

And I agree. It would be impossible to get these functions 100% accurate from the file/folder name string alone. I realise and accept that.

Instead I'm striving for as close as I can get to 100% accurate

Originally Posted by romperstomper

Also, you can use '.' in a folder name.

True. But I rarely ever see this occur on the systems I use.

(I could slightly reduce this risk by only checking for the '.' after the last '\' in the string. The problem with that is that I am then assuming the input argument is a FullName. It wouldn't work too well if the input was a FileName!)

Originally Posted by romperstomper

In short, your goal is not achievable, but don't let that stop you.

Thanks Rory, but I'm thinking I didn't make my goal clear enough. I know it would be impossible to achieve 100% accuracy. And that's not what I was asking for in the OP. I asked if anyone could tighten the functions any further. (If you like - think of it as a theoretical challenge! )

Originally Posted by Kyle123

Pretty sure Dir() does this pretty well

It does?

I've found that Dir only works where the file or folder exists on the computer you are working on.

i.e. If you Dir a string where the file or folder doesn't exist, it will return an error. This error forms the basis of the ExistsFileFolder function written by Ken Puls (see my badly rehashed copy below)

Please Login or Register  to view this content.

Originally Posted by Kyle123

Code should check at runtime for the existence of a resource before trying to consume it, so this point is irrelevant.

You are right. It should.

But I still want to see how far I can take these functions anyway

A FileName does not, can not, have a Drive prefix - unlike a FullName or Path. (Note: can not = if it did then the string is not a FileName, it would be a FullName)

So IF the input strings 2nd & 3rd characters are ":\" OR the first two characters are "\\" THEN ... (Note: "\\" for those pesky UNCs)

hmmm I think I might be onto something here

Latest version. I've now eliminated 1 bad result from 2 of the functions (by using a reasonable assumption)

Please Login or Register  to view this content.

never mind ...

With the single exception of tightening a single character input in one of the functions (UPDATE: now solved), I think that I now have it as accurate as it can possibly be.

Please note that since we are acting from the strings alone and without Dir/FSO access to the original files/paths, it is simply not possible to programatically determine the difference between:

1. a FileName/FullName without a FileExtension
2. a Path without a trailing Path Separator

I have tried to minimise this risk by adding an optional boolean argument which allows the end user to choose which of the above two they want to err towards.

The functions are provided for anyone to use if they want.

Any feedback (good or bad!) is welcome.

Please Login or Register  to view this content.

Discovered an error recently - I had the boolean argument around the wrong way. Updated function below:

Please Login or Register  to view this content.

Originally Posted by mc84excel

With the single exception of tightening a single character input in one of the functions (UPDATE: now solved), I think that I now have it as accurate as it can possibly be.

Famous last words.

I have recently encountered some real-life examples of file names that are not handled correctly by these functions. I will reopen this thread until I solve them.

SCENARIO 1:
Copy this into the Immediate Window. It will give the wrong result. The test filename used explains why.

Please Login or Register  to view this content.

SCENARIO 2:
Copy this into the Immediate Window. It will give the wrong result. The test filename used explains why.

Please Login or Register  to view this content.

Both the above examples will return the correct result if we ignore the optional boolean argument "blnRemoveMultiExt".
However doing this creates a problem when a filename contains a fullstop as well as multiple file extensions.


A quick explanation on the concept of multiple file extensions.
Some programs create output files with a file extension that has more than one full stop. e.g. FileName.001.FileExt, FileName.002.FileExt etc.
In these cases, the end user may want to return "FileName" instead of "FileName.001" etc.
These are what I call multiple File Extensions (if anyone can suggest a better descriptive name and/or a clearer explanation of this concept I would be grateful)


Thoughts on possible solutions
As stated before, these functions can only use the file/folder strings only - the files may not be on the computer we run the code on so we cant make use of FSO. This makes the whole exercise very challenging.

Example 2 - I could try using MID to check backwards 1 or 2 characters from the fullstop position = "v"/"ver"/"ver."/"v."

Example 1 - I could try to set a maximum limit on the len of each expected file extension. E.g. if the full stop is more than 5 characters from the previous full stop then it is assumed that this section is not part of a multiple File Extension