I'm working in AutoIT to script a basic task I'll have to repeat on 50ish workstations.
I need to copy a directory and it's subdirectories and files (recursively) to a network share as a backup. For some reason, DirCopy() does not work at all.
I've tried running it on several different directories (thinking permissions issue, I'm Domain Admin account), tried doing a RunAs (again thinking permissions), and also put the #RequireAdmin tag to force the program to run on an elevated account. Nothing has worked. I can't even get it to copy empty directories.
DirCopy(#DesktopDir & "\SAMPLE\TEST1", #DesktopDir & "\SAMPLE\TEST2", 0)
Please advise!
Just figured this one out.
Turns out DirCopy() is a pretty stupid function that cannot handle if the destination directory already exists (it wants to create it for you). So if you kill the destination directory, then run the above code line, all woks as expected. But then if you add a new file into the source directory (TEST1 in my example), then it breaks again and does nothing.
Go figure...
Now time to find a work-around using something like xcopy...
Related
Every time I open brackets, it points to a start-up folder instead of previously opened files and folder. Is there a way to retain previous session?
It should remember what folder you had open, so it's hard to know exactly why not. Here are some things to try though:
If you have any extensions installed, try uninstalling them. (If that fixes it, you can reinstall them one by one to see which one was the problem).
If you select Debug > Show Developer Tools in the menu, are there any errors listed in the Console tab?
If you select Help > Show Extensions Folder and then go up one level, is there a state.json file there? If so, try deleting/renaming it to see if that fixes things. If not, make sure the permissions on that folder are ok.
I have one server that works (that I originally remember took me a loooong time to figure out--dont remember solution). I copy the exact same permissions to the new server, and it does not work. 'Everyone' is given total permission.
I have given permissions to _IUSR, IIS_USR, and Everyone., yet I still have errors with PHP trying to write/modify files.
Whats up?
You didn't mention IIS version you are using and what's application you are trying to run on top of it - these would be helpful to get a proper answer.
Looking at account names you mentioned you are running IIS 7.x... If you are running app which requires some fancy permissions config on its folders and files just try to temporarily grant full access to Everyone and IUSR from the top of app folder (overwriting everything below it) just to verify that this is permissions problem indeed.
Is there a script or something that can check if all core files are installed properly. I am installing a Wordpress site on clients hosting, and for some reason around 100 files were not transferred due to the connection time out. Now I am moving them one by one, but still I would like to check somehow, once I am done, that all files transferred are there and their size is more than 0b.
Thanks.
Since you are using Filezilla, drag and drop all files again into the folder.
Then when the file exists message shows up, pick Overwrite if different size and check apply to current queue only. Then only the ones with different sizes (or the ones that weren't transferred) will be overwritten/updated.
There's an easier way:
If you have access to some kind of control panel like cPanel, you can make a .zip file and upload it only via Filezilla.
Then on cPanel, go to File Explorer and unzip from there. Will be faster and you just have to upload one file (rather than opening tons of connections and giving you timeout).
Or if you have shell access, you can login with your key using Terminal(mac) or Putty(win), browse the folder and run the unzip command.
I've developed an ASP.NET v4 web app which I am trying to get to write to a folder in the webroot.
For the life of me I cannot get Windows 7 to allow it to write a file, I get Access is Denied error each time.
What I have tried on the folder is
attrib -r /foldernameandpath
attrib -r -s /foldernameandpath
Removing Check from ReadOnly attribute in folder properties
Changed owner to folder to current user whom is also the admin
Changed owner to Everyone
Adding Everyone user to folder with all permissions
Changing the folder to the Public Document directory
Changing to the root of the C drive (Out of desperation)
Nothing seems to work and all I want to do is test that the write works.
Now I know the system works and writes fine cause I had this same web app on a second machine writing the PDFs to the C drive without issue. This second machine I just cannot get it to allow the write.
Oh please for the love of all things holy, put the keyboard and mouse down and stop what you are doing. Some of the actions in your list seriously frightens me.
All the things you list as your actions are most likely useless or desperately random at best.
As a web developer, you shouldn't have to start messing around changing ownership of folders, especially not the web root folder normally used by the web server. When you do, you'll end up in a dark, cold and lonely place. Lord only knows what other desperate measures you have taken. For your own sake, I'll recommend you to do a system restore or even system reinstall to make sure you are in a healthy state.
Let's go back one step and try to sort out what you are doing.
First: what is the path you are trying to write to?
Second: are you running this application directly from within Visual Studio or in IIs?
If you are doing the first option then your current user account is the account who tries to write to the path in question. Do you have write permissions there?
One thing you can try is to start Visual Studio with elevated permissions and see if that works.
If you are running in IIs, it the associated pool account that needs write permissions.
Are you doing impersonation by any chance? If so, make sure the impersonated account have proper permissions.
You should only write to a predefined folder within your app path, like ..\App_Data for example.
The easiest way to find out which account you are running with and determine what path you are trying to write to, is to fire up SysIntenals process monitor and find the entry with the access denied result. Select properties for that entry and find out which account tried to do the write action. When you have determined that, right click on the folder in question and give the proper account write permissions.
I would like to move a test Drupal installation from
/opt/lampp/htdocs/corporate/internet
to
/corporate/internet
What corresponding changes changes do I have to make in .htacess, settings.php and/or other settings?
That depends on that how your sites/ directory is set up. If you just have a default directory within, they you really should be good to go.
Mostly, you don't have to make changes. This is because Drupal installations tend to be set up to use relative paths that will be valid no matter where in the system it is. You may want to do a quick search of any custom code for the string /opt/lampp/htdocs to see if someone didn't do something relatively, but any other contrib code should work fine.
As Jubal mentions, sites set up in the sites directory may need renaming if you're going to be using a different URL to access the site - if you're moving from devel.site.com to www.site.com, and you have a sites/devel.site.com directory, then you're probably going to want to copy that directory to sites/www.site.com. On the other hand, if you're using sites/default for your site, or if you're not changing the url at all, then this isn't a problem.
Do note that the .htaccess in the root directory of Drupal is very important for Drupal to work, and that doing a simple cp -R of the directory will not copy the .htaccess, so make sure you copy that. (.htaccess files in sub-directories, like sites/default/files, will be fine, it's just this one in the root.)
And finally, check your file permissions after you move the files. You'll especially want to make sure that the file permissions for the files and tmp directories are correct so that people can properly upload files. (This may not be important - but it's something to check nonetheless.)