Jump to content
Sign in to follow this  
Selmak

FileFindFirstFile behaviour change

Recommended Posts

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?

Share this post


Link to post
Share on other sites
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 by The Kandie Man

"So man has sown the wind and reaped the world. Perhaps in the next few hours there will no remembrance of the past and no hope for the future that might have been." & _"All the works of man will be consumed in the great fire after which he was created." & _"And if there is a future for man, insensitive as he is, proud and defiant in his pursuit of power, let him resolve to live it lovingly, for he knows well how to do so." & _"Then he may say once more, 'Truly the light is sweet, and what a pleasant thing it is for the eyes to see the sun.'" - The Day the Earth Caught Fire

Share this post


Link to post
Share on other sites
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.

:)


Valuater's AutoIt 1-2-3, Class... Is now in Session!For those who want somebody to write the script for them: RentACoder"Any technology distinguishable from magic is insufficiently advanced." -- Geek's corollary to Clarke's law

Share this post


Link to post
Share on other sites
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.

Share this post


Link to post
Share on other sites
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 ".".

:)


Valuater's AutoIt 1-2-3, Class... Is now in Session!For those who want somebody to write the script for them: RentACoder"Any technology distinguishable from magic is insufficiently advanced." -- Geek's corollary to Clarke's law

Share this post


Link to post
Share on other sites
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 ;-)


"So man has sown the wind and reaped the world. Perhaps in the next few hours there will no remembrance of the past and no hope for the future that might have been." & _"All the works of man will be consumed in the great fire after which he was created." & _"And if there is a future for man, insensitive as he is, proud and defiant in his pursuit of power, let him resolve to live it lovingly, for he knows well how to do so." & _"Then he may say once more, 'Truly the light is sweet, and what a pleasant thing it is for the eyes to see the sun.'" - The Day the Earth Caught Fire

Share this post


Link to post
Share on other sites
PsaltyDS

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

Good point. :)


Valuater's AutoIt 1-2-3, Class... Is now in Session!For those who want somebody to write the script for them: RentACoder"Any technology distinguishable from magic is insufficiently advanced." -- Geek's corollary to Clarke's law

Share this post


Link to post
Share on other sites
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 by Selmak

Share this post


Link to post
Share on other sites
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 by dabus

Share this post


Link to post
Share on other sites
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.

Share this post


Link to post
Share on other sites
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 by Selmak

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
Sign in to follow this  

×