FileFindFirstFile behaviour change

[Selmak]

Been trying to convert a script from an earlier compiler to a recent one, and and hit an awkward problem.

Reason turns out to be that since 3.2.0, FileFindFirstFile no longer returns the 'dot' entries in directory listings. Unfortunately the scripts in question rely on these entries being present for their correct action. The code cannot easily be altered to allow for the change in behaviour of the function, at least not without major rework.

Q: Is there any way of reinstating these entries, like a 'show dots' config value?

[The Kandie Man]

I am afraid I don't believe there is a way. I have a question though. Why is it so important that the dots be returned? If i remember correctly, it always returned a single dot meaning the current directory followed by a double dot meaning the parent directory. All directories will return a single dot and only the main drive directory will not have a parent directory. So I am afraid I don't understand why it is so important that the dots be included. If you were to go into detail, perhaps we would be able to write a simple function that simulates the return of the dots the way FileFindFirstFile originally did, though I am still not sure why it is so important.

-The Kandie Man ;-)

Edited May 7, 2007 by The Kandie Man

[PsaltyDS]

What value are the '.' the '..' entry? Are you using them to see if the returned string is a file or directory? Might want to use _FileListToArray() instead, which has switches to only return directories or files.

[Selmak]

What value are the '.' the '..' entry? Are you using them to see if the returned string is a file or directory? Might want to use _FileListToArray() instead, which has switches to only return directories or files.

That might be a workaround, but implementing it is going to be a major rewrite.

In this case the .. entries are used to determine that the directory contents are accessible over the network, so simulating them would defeat the purpose. As you can imagine, without them the script works in most circumstances but bugs-out on a folder with no files.

Though, I have other scripts that compile arrays of file-lists, to do jobs like backups, and the behaviour of these would need to be very thoroughly retested in view of the change. They might be affected... or maybe not. Hard to say offhand.

Basically, my two cents-worth is that it's not a good idea to make changes like this, at least not without very good reason. Debugging is an exhaustive process at the best of times, and if functions start to show subtle changes in their behaviour, then this effectively throws the whole project back to Alpha status.

[PsaltyDS]

That might be a workaround, but implementing it is going to be a major rewrite.

In this case the .. entries are used to determine that the directory contents are accessible over the network, so simulating them would defeat the purpose. As you can imagine, without them the script works in most circumstances but bugs-out on a folder with no files.

Though, I have other scripts that compile arrays of file-lists, to do jobs like backups, and the behaviour of these would need to be very thoroughly retested in view of the change. They might be affected... or maybe not. Hard to say offhand.

Basically, my two cents-worth is that it's not a good idea to make changes like this, at least not without very good reason. Debugging is an exhaustive process at the best of times, and if functions start to show subtle changes in their behaviour, then this effectively throws the whole project back to Alpha status.

Easy fix (which I used to use a lot in .cmd batch files): look for NUL, i.e. test for C:\Temp\NUL. NUL is a reserved keyword and exists as a pseudo-file in every directory. So if you get "C:\Temp\Test" and don't know if it might be a directory, you can test for "C:\Temp\Test\NUL". This leaves you with a problem, but not more so than your original test, and that is the possibility that thre is BOTH a file AND a subdirectory called Test in C:\Temp. Using _FileListToArray() helps avoid that, but testing for NUL will at least work as well as testing for ".".

[The Kandie Man]

You could always use FileGetAttrib() to see if the current path is a directory:

If StringInStr(FileGetAttrib("C:\Windows"),"D") Then
    Msgbox(0,"Directory",'"C:\Windows" is a directory.')
Else
    Msgbox(0,"Not a Directory",'"C:\Windows" is not a directory.')
EndIf

- The Kandie Man ;-)

[PsaltyDS]

You could always use FileGetAttrib() to see if the current path is a directory:

Good point.

[Selmak]

Perhaps I should have made it clearer, that the objective is to check whether or not a network share is available to the user.This is not as simple as is sounds, since a mapped share may become inaccessible if it 'Disconnects' - a problem often encountered on buggy servers - also it is perfectly possible to establish a connection to a share in which the user has zero rights, either to the share itself or to NTFS files within. In either case it will seem that you have a connection until you try to read or write, when you hit the problem. I need a way to forestall the problem by determining whether it is possible (at the very least) to enumerate the files in the share. If this is not possible then we assume a network fault.

The problem arises when the system is newly installed - the share being empty - the lack of '..' or NUL means there is no way of establishing whether the contents can be read. That basically is my problem.

Initial tests suggest that none of these methods will work.

_FileListToArray() calls FileFindFirstFile() so I don't see how it can avoid the issue.

FileGetAttrib() does what you would expect it to, that is it reports that the directory you are checking... is a directory. Which may be a good point, but doesn't help since an inaccesible directory will still be reported as such. (Which is logical behaviour, after all the question was 'Is this a directory?')

NUL should in theory work, as it does in batch files ( if exist folder\nul ) but in fact it doesn't work here. When writing these functions I had originally intended to use NUL, and its not working was why I switched to '..'

I'm thinking the best answer might be DLL calls, that way I could write a replacement function that does return dots, and the code mods would be simple a find-and-replace job, much easier than a rewrite.

Edited May 8, 2007 by Selmak

[dabus]

If it's a small amount of servers, just create a share that's readable for all (like \\192.168.0.1\test$). Put a file into the share. This share is not visible, just like the admin-shares. Use something like

If FileExists ('\\192.168.0.1\test$\dummy.txt') Then MsgBox (0, 'Test', 'Connected')

You dont't even need that if you search for wildcards...

Edited May 8, 2007 by dabus

[Selmak]

Put a file into the share.

Won't work if the share is readonly. Also I suspect (though haven't actually tested) that it may give misleading results with NTFS issues, since the script will be the 'owner' of the file and will thus automatically have full permissions.

No. What is needed is a reliable way to check if a particular share is accessible over the network, and that the user is able to list its contents (even if none other than 'the dots') in a typical Windows dialog-box without this action throwing an error.

Using 'the dots' to make the test is 100% reliable on Windows, and on Linux servers provided the "Show Dots" Samba parameter is true. So far it's the only reliable method I know of, other than those that depend on special cases like preinstalled test-files.

As this must work in a general case, no assumptions can be made about rights or permissions, etc. If there are any other ways that achieve this then they might be suitable. But they must work without making any special assumptions about the share.

[Selmak]

OK, solved it - listening to Steve Hillage probably helped my lateral-thinking processes

Simple workaround would be to pass the parameters to an .exe compiled with an earlier release which calls FileFindFirstFile, and returns an exit code indicating network-resource OK or not OK.

Perhaps not as efficient as a DLL call but saves hours hunting-around on Technet for the right call to make. Since the test only needs done once per session (file listings being done with the new syntax, for which we don't need the '..' entries) it should impose only minimal overhead anyway.

Glad I've got that cracked anyway, as it means I can start using the new features in 3.2.

Edited May 8, 2007 by Selmak