Changing user permissions > CRASH!

Yesterday running Hyena 2.5.1 on a Win2k desktop, I attempted to change file/directory permissions on two different NTFS volumes, on two NT 4.0 network servers.

Both sets of changes were running and in the midst of applying the new rights throughout the directory structure, when they gave me (a domain admin) an 'access denied' message.
Thereafter I could not access the volumes across the network or from the server console itself. Under disk administrator, on each of the two servers it showed the volume was there, but with with no associated file format. The volumes remained inaccessible even after a restart on the server.

Have you seen any problems like this before?

Early last year we had some strange (I can't remember details) problems when adjusting rights on an NT server, using Hyena from a Win2k client. Since then, with the exception of yesterday it has worked fine.

Yesterday, we lost nearly 50GB of data and were still doing restores at 3 o-clock this morning.
I love Hyena, but can I trust it?

Wayne

[cmccullough]

Re: Changing user permissions > CRASH!

Thanks for reporting this problem to us. I don't want to sound like a vendor that does not own up to problems in our application, but I am about 99.9% sure that Hyena is not the application at fault here. Hyena does not actually carry out any of the file/directory permission modifications. When you display the file properties dialog for a given directory, Explorer is actually displaying the dialog, and it also carries out the action when you click OK. We designed Hyena this way for a reason: because recursively going through a file/directory structure is both complex and if something does go wrong, we did not want to be responsible !. Put it another way, there are a LOT of variables with remotely going through files/directories and changing them on a network, and Hyena does not contain any of the code that actually does these actions.

I would suspect that the cause is either a hardware problem, or some sort of error condition that NT/2000 itself got, which it could not recover from. I almost wish that I could explain your problem, but since we have such a hands-off approach to handling NTFS permissions, this is one that I can't even guess at, since we don't actually perform the processing.