PATHNAME$ -- inconsistent results

[Richard Marchessault]

I am getting a strange result using this function.

X$ = "C:\Temp\Test.cfg"

PATHNAME$(NAME, X$) most often returns "Test" but sometimes returns "Test.cfg"

I cannot determine why this does not work reliably. Any ideas?

More detail. The actual X$ is being filled when I am doing a SAVE AS file function. If the SAVE AS is to the current folder, then PATHNAME$ works fine. If the SAVE AS is to a new folder, then PATHNAME$ returns the file name with the extension. Could there be an invisible character in X$ that is causing this problem? Msgbox display shows that the length of the X$ string is correct and it displays as expected. This is driving me crazy.

MORE INFO:

This is most likely a Vista issue. The code works fine if I don't save to C:\temp folder. I can live with that but I would like some way to know that the folder a user selects will or will not be appropriate. I thought perhaps the OFN_NOREADONLYRETURN flag would do this for me but it does not help.

When I check the properties of the C:\temp folder it comes up with "Read only" checked although I can copy files to the folder using Explorer. It lets me uncheck the read only box and apply the change but the change does not stick.

Any suggestions?

[Gary Beene]

Richard,

Have you checked the file name in Windows Explorer to confirm that it's being saved as the name you expect?

I've had a problem before of accidentally generating a filename like "myfile.txt.txt", which gives the result you are seeing.

#Compile Exe
#Dim All
Function PBMain () As Long
    Local x$
    x$ = "myfile.txt.txt"
    MsgBox PathName$(Name,x$)
End Function

This returns "myfile.txt"

[Richard Marchessault]

Files

A number of files need to be written to the folder to successfully complete the "Save As". When I save to a folder other than "C:\Temp" the files are all written to the folder. When I save to "C:\Temp", the files are not saved to this folder. I've tried to use the ISFILE and DIR$ functions to check whether the files have been successfully written to the folder. The odd thing is that in both cases PB will tell me that the files are there but Windows explorer shows that they are not there. I also tried doing a FLUSH before testing for the files but PB still reported that the files were there. This is very frustrating. No problem if I cannot write to a particular folder but how do I test for the problem when PB reports success when there if failure.

[Brice Manuel]

Richard Have you checked your virtual store?

[Richard Marchessault]

I've checked in

C:\Users\Dick\AppData\Local\Temp

but none of the files that should be in C:\Temp are there.

[Brice Manuel]

They are being written to your virtual store, because you are trying to write them to a location you do not have permission to write to.

"Save As" is different than "Save" when dealing with permissions and file virtualization on Vista.

If you look in your virtual store they should be there.

[Tom Hanlin]

Windows has some bizarre ways when it comes to file and folder handling. There are a variety of cases where what you see is not what you get.

You might start by checking your Windows settings to make sure that it is not hiding file extensions for registered extension types.

You might also be aware that newer versions of the operating system have done something like making system links, or aliases, to certain system folders. What is now \Users used to be buried in something ghastly like \Documents and Settings\Users ...it sounds like your \Temp folder could possibly be a link to a different location altogether.

Try saving a file with a unique name, then run a Search for it, and see where it turns up.

[Brice Manuel]

PS: Your Virtual Store should be located somewhere like this:

C:\Users\User_name\AppData\Local\VirtualStore

You can read up on virtualization here:

http://msdn.microsoft.com/en-us/library/bb756960.aspx

[Richard Marchessault]

Sounds good but the files are not there. When the files are written to C:\Temp they just disappear.

What I really would like to know is how to use PB to determine that this has happened. The standard functions tell me that files exists that do not exist. No error occurs when the files are written but if the program tries to open up these phantom files, they cannot be found.

[Stephen Rodriguez]

They are being written to your virtual store, because you are trying to write them to a location you do not have permission to write to.

"Save As" is different than "Save" when dealing with permissions and file virtualization on Vista.

If you look in your virtual store they should be there.

Bugger me - I was going nuts earlier this week wondering where the heck some files I had tried to extract to my programs folder had gone? They were there, but not there - just like the problem Richard is experiencing. Thanks Brice, you just pointed me to the correct location!

[Arthur Gomide]

Try this:

MyTempPath$ = ENVIRON$("Temp")

and see what happens .

[Richard Marchessault]

While it is interesting to try and find the missing files, my problem is how to let a user know that the files will not be saved in the folder they selected in the Save As dialog. I don't see anything in the thread so far that will help me. My work around which is not very robust is to use the fact that PATHNAME$ returns the wrong information when such a folder is accessed. If I find the wrong information, I know that the user needs to pick another folder for the save. I inform the user of the situation and restore the data from the original folder. Working great so far but this solution will fail if PATHNAME$ starts returning the correct information while Windows continues to not save the files in the intended folder.

[Michael Mattias]

Unless this does not apply on Vista(r) systems (but it probably does), you can save yourself a lot of trouble down the road by NOT allowing the user to pick a path, instead having him save to some 'known folder' at or below either the %CSIDL_APPDATA (user-specific) or %CSIDL_COMMON_APPDATA (available to all users) folders.

Alternately, if you need to ask for a folder/file, you can prevent him from selecting certain folders by utilizing the callback features of the GetSaveFileName function or the ShBrowseForFolder function.

Same with finding files later: if you know the file is located 'at or below' some known folder, you can start the user there and not allow him to "go up the tree"

No, this is NOT "PowerBASIC 101", but it IS do-able.

If Windows is going to virtualize some folders, you're just going to have to deal with it; and the easiest way for the long term may well be to avoid dealing with folders which can/will be virtualized.


MCM

[Brice Manuel]

Bugger me - I was going nuts earlier this week wondering where the heck some files I had tried to extract to my programs folder had gone? They were there, but not there - just like the problem Richard is experiencing. Thanks Brice, you just pointed me to the correct location!

NP, SROD.

While it is interesting to try and find the missing files, my problem is how to let a user know that the files will not be saved in the folder they selected in the Save As dialog. I don't see anything in the thread so far that will help me.

Read the link I posted. You as the programmer need to abide by the guidelines for Vista development to ensure your EU will not have a problem. You should not try and write files into directories that you are not supposed to access. Although virtualization works for now, you should NOT rely on it as MS has made it clear this isn't future-proof as virtualization will not always be there in the future. You should also make sure your app is requesting the correct permissions/privileges that it will need.

[Michael Mattias]

Good start....
Explorer-Style hook Procedures for OpenFileDialog and SaveFileDialog 3-31-07