:p

There is a "read only" flag for folders as well as files. The difficulty is that if a folder is set to read only then you can't add/delete/rename files inside it either.

I think there's a way to make it harder though. More than once I've had Windows refuse to delete a folder until I first deleted all the files or was it folders, inside that folder.

Bob.

Oooooh, there's a thought. Create a file inside the folder, set it to read-only, hidden, and system. That way no one can delete the folder with that file still in it, and all but advanced system users are unlikely ever to know the file is there.

[]..all but advanced system users are unlikely ever to know the file is there.[/i]

I've learned the hard way that some students are smarter (or more malicious) than we give them credit for :-(

Mike

Well, true. But if the idea is to avoid mistakes, those making the mistakes are unlikely to be trying to subvert the system.

If you're dealing with Students... as In:
- Project File
- Media

I would suggest making a 'Read Only' Folder which contains these items or File Structure as you see fit to teach. They have to Copy this FOLDER to their working/project drive where it has Read/Write rights. They work from the Working/Project folder and if they delete something they can always copy it back over.

-or-

Have them work/call for the Media in the 'Read Only' Folder but have to save their project in a Working/Project Folder. This would allow for multiple classes & students to work using the same Media Pool yet NOT be able to alter it and with no need to duplicate it. YOU would have total control of all the assets and this would give them a 'Real World' feel.

-Here we have a RAID that houses all the B-Roll that can be reached from any workstation. If your workstations are networked you can set up 1 RAID system to house your Media and have all workstations call for the Media from there. All workstations save their Projects locally according to your file system.

i made a folder, put a file in it, make it read only & hidden.

the folder was deleted w/o any issues.

Not since DOS has MS actually stopped you from "accidentally" deleting read only files. Windows doesn't care, it still deletes them. And even if you put a system file in there that windows reads, it will most likely delete everything else & then stop when it hits that file.

I have accidentally created files and folders which cannot be deleted. It usually involves files copied over from other O/S file systems. If you want to do this intentionally, the "secret" is to create one of the situations defined in this Microsoft KB article:

You cannot delete a file or a folder on an NTFS file system volume

The method I would try to follow is the one suggested by "Cause 6:" The file name includes an invalid name in the Win32 name space. This is what has caused every instance of undeletable files that I've experienced. If I wanted to do this on purpose, I would create a bootable Umbuntu disc (I always have one on hand -- it is a wonderful troubleshooting tool) and then create a file or folder name that is slightly illegal under NTFS. I would stay away from big-time illegal names (like ones with a colon in them) and instead try something like what is shown in the link above, namely a file name that contains a trailing space -- something not allowed in Windows.

There is potentially some small hazard in this approach because it is possible that some Windows calls won't see the folder, but in my experience that wasn't a problem.

You can delete the file or folder without re-booting to Umbuntu by opening up a CMD box and simply doing a del *.* or deltree with a wildcard. If there are files you want to keep, move them before executing the wildcard delete command. However, any attempt to delete the file or folder by just using Windows Explorer will fail.

This is slightly advanced stuff, and a little unorthodox, so don't do it if you are uncomfortable with such things. However, it will create files and folders that cannot be easily deleted by simply turning off the read-only attribute. Even fairly advanced users will have a tough time figuring out how to delete the file or folder.

thanks one and all,

very interesting......

i have to say i tried all the above suggestions re 'file' within folder; hidden, read-only, system, etc., but it was as easily deleted as ever.

john's suggestion re unbuntu looks interesting, but a lot of pc's i teach with (on?) are in schools and the like, and though i have admin rights, i'm not willing to take this route as i might well screw up something (i find the it at most of these places a law unto themselves, and the more meek and mild and subservient i am to their self imagined 'genius' the more likely i am to gain their co-operation).

i might add that most of these folder delets are NOT malicious or intended, just plain stupidity (and which of us hasn't deleted a important folder at one time or another? - let he who pressed the delete button first, press it again).

if anyone comes up with further ideas i'm all ears,

thanks,

leslie

john's suggestion re unbuntu looks interesting, but a lot of pc's i teach with (on?) are in schools and the like, and though i have admin rights, i'm not willing to take this route as i might well screw up somethingThe files I've not been able to delete were all files I've received on external drives. Therefore, you might try creating an illegal file name on a thumb drive or external hard drive and then see if you can drag/drop it to a new location. If I remember correctly, you probably will not be able to grab the illegally-named folder and then drag it directly, but if it is contained within another folder that is legal, it should be able to be moved across. If so, you won't have to mess with booting these school systems on another disk or re-set permissions. It's worth a few minutes to try on your system at home, I would think.

why not tell the kids if they delete their stuff they fail? Might wok after a few take home their report cards. It's the equivalent to throwing your text book in to the fireplace, as don't have security systems on those, do we: ;)

even if you're dealing with younger kids. my kids know how to NOT delete files/folders: it's pretty easy, don't!

One old trick I recall was using VB to create a file with the backspace character in the name.

Bob.

well;

john - i've tried this way and that to create illegal names for both files and folders on a thumb drive - all of which i could delete once transferred across....

hf - i'd be happy to fail the buggers, i've even talked to my various superiors, all of whom give the benefit of doubt to the students (inept as they might be). so other than the 'old fart' routine of trying to warn them (did you ever listen to some old fart when he told you to be careful?)

bob - can you hallucinate? oops, elucidate please

leslie

did you ever listen to some old fart when he told you to be careful?

the second time, yes. :D

In my shop the rule is, if you deleted something you shouldn't have, you're responsible for getting it back. End of story. Seems to work remarkably well.

As John's link pointed out ... one reason a folder\file will not be deleted if it is being used by a process. So, if you had a process which was always running and used that folder you shouldn't be able to delete it.

I was able to get this to work by creating a simple vbs script (see below) which sets the current directory to a folder you might want to protect and then loops infinitely (you'll have to manually kill the wscript.exe or cscript.exe process with taskmanager if you really want to delete the folder). You could launch this from the StartUp folder so it always runs after boot up.


Set wshShell = WScript.CreateObject("WScript.Shell")
wshShell.CurrentDirectory = "C:\ProtectedFolder"

Do
WScript.Sleep 1000
Loop


Hope this helps,

Cheers, Scott

Are the computers networked and / or do the users have to log onto them? If so (and I know this works if they're part of a domain), you can control the folder (and / or any files within the folder) with user permissions. I'm not on a Windows computer at the moment and may not get all the details right, but we use this at work. What I'm describing is based on a Windows domain using the NTFS file system.

Basically you need to set the permissions on the folder so the user has permission to read, but not delete the folder. Ideally, on a domain, the students would be part of a group of users ("students" for example) so you don't have to manage the permissions on a per-user basis. Instructors (who may need to be able to make modifications) might be in a different group ("staff").

Our workstations run XP Pro; I've not dealt with it on Vista personally. I know our domain enforces these restrictions on Vista or OSX machines that are on the domain. Ideally, the folder itself would be on a file server (one place for everyone). You can create a desktop shortcut on each machine if wanted. A right click into either "Properties" or "Security" will get you started. There are some basic settings and of course there are more granular "advanced" settings. You'd select a user or a group that you want to change the permissions for ("students" group), define what they can / can't do and select whether the new permissions should also apply to the files / folders beneath the one you're working on. It can get complex and confusing, but it doesn't have to. So long as you're working with a test folder that you're in control of, there shouldn't be any risk of you making irreversible mistakes in testing. We use this to control permissions on folders on a server.

If they're not on a domain, but if each machine is set to require users to log on, it should still be useful (you, as a user with higher privileges has full control over the folder; the student logon has the restricted permissions over the folder).

Wish I was on a Win machine at the moment so I could give better instructions....

Rick

thanks scott and rick, both very useful suggestions indeed.

i also posted to win7 forum, and got this reply if anyone's interested:

http://social.technet.microsoft.com/Forums/en/w7itprosecurity/thread/dd9be612-b2ee-4690-9001-7c089ac92bbc

again, thanks everyone for all your help......

leslie