When I start copying all images from the container into an empty folder it asks if I wish to overwrite the file. Why this is happening? I have got /s argument specified to do recursive download. As I see it downloads into the right directory structure. File must be unique so this question should not be asked.
I use next command
AzCopy /Dest:C:\images /Source:https://*.blob.core.windows.net/images/ /SourceKey:a_key /s
Is it a bug or I do something wrong?
This is a known issue and there isn't anything to fix from AzCopy's side. Names of Windows file system is case insensitive, which is by design and can't be configured. To work around this issue, please rename one of your blob to avoid distinguishing blobs only by capitalization.
Related
I have a powershell script, in it calls azcopy to list, download then delete the files from azure blob, all runs good except there a few .azDownload+guid prefixed files show up.. now what i do with those files, it seeems some of them are legitimate files, just the prefix is the issue, how can i fix it?
found it, it appears azdownload was an interim file produced by azcopy, simply put in a delay script before downstream able to pick up solve the issue.. would it be better if azcopy can write the temp/interim file somewhere else to avoid confusion!
I'm trying to upload a .zip file to a location on a remote server.
In my fabfile.py I have this line:
local("rsync files.zip webfaction:~/webapps/app")
This completes without a problem. However when I ssh onto the box, I find that rsync put the files.zip file in
~/webapps/app/Users/kevin/resources/files.zip
Where I really just want to put it in webapps/app without copying the local file structure. What can I do to avoid having rsync copy over the local file structure along with the files?
Thanks,
Kevin
rysnc does not copy the local folder structure if it is not included in your command (don't think it will even if you specify it).
Are you sure you got the command correct? If so, I guess it could be something to do with how Python locates the file through the local() method.
Not much help, but I hope it'll provide some clue...
Since you're using Fabric, why aren't you using the put() api call?
I am using installshield 11 to create Basic MSI Project. My requirment is, when i unstall the project, i want to preserve certain files.( I don't want these Certain files to be removed when unstallation takes place ). Morover, these files are not a part of the component, but they are created(copied) during installation process by using copyfile (script) command from specific location.
-Dev
Use Disable(LOGGING)....Enable(LOGGING). Using CopyFile() in-between these methods will prevent uninstall removing the files
Windows installer removes only those files and folders which it installs. That is each file present in it's database in File table and Folder table. It do not remove any file which does not have entry in File table, similar for folder.
Also, If folder is not empty then that folder does not get deleted during uninstall.
If your installing some files using Copyfile script ( may be using any custom action) then those files will not be removed during uninstall.
Thanks Balachandra for your response, But i have below observation which might help.
Files which i want to preserve is created by CopyFile, and target dir which i mention in the copyfile command does not exist. So CopyFile creates the folder and copy the file to that folder. So obviosly we will not have this folder entry in the dir table of installsheild
But this approach does not help, uninstallation is removing all copied files from this folder.
-Dev
Thanks, Alerter, I've been fighting this one for 2 days.
We install an example configuration file and create a copy of it (on first installation). We needed to preserve the configuration file if the customer changed it, but the file was always getting deleted on uninstall. Disabling the LOGGING around the CopyFile command was exactly the solution for this situation.
Dev, I know this is an old post, but you should accept this as the correct answer.
Hopefully this phrase will help others find this solution easier through the search engines: Installshield file created with CopyFile is always deleted during uninstall
I am trying to write a script or a piece of code to archive files, but I do not want to archive anything that is currently open. I need to find a way to determine what files in a directory are open. I want to use either Perl or a shell script, but can try use other languages if needed. It will be in a Linux environment and I do not have the option to use lsof. I have also had inconsistant results with fuser. Thanks for any help.
I am trying to take log files in a directory and move them to another directory. If the files are open however, I do not want to do anything with them.
You are approaching the problem incorrectly. You wish to keep files from being modified underneath you while you are reading, and cannot do that without operating system support. The best that you can hope for in a multi-user system is to keep your archive metadata consistent.
For example, if you are creating the archive directory, make sure that the number of bytes stored in the archive matches the directory. You can checksum the file contents before and after reading the filesystem and compare that with what you wrote to the archive and perhaps flag it as "inconsistent".
What are you trying to accomplish?
Added in response to comment:
Look at logrotate to steal ideas about how to handle this consistently just have it do the work for you. If you are concerned that rename of files will make processes that are currently writing them will break things, take a look at man 2 rename:
rename() renames a file, moving it
between directories if required. Any
other hard links to the file (as
created using link(2)) are unaffected.
Open file descriptors for oldpath are
also unaffected.
If newpath already exists it will be atomically replaced (subject
to a few conditions; see ERRORS
below), so that there is no point at
which another process attempting to
access newpath will find it missing.
Try ls -l /proc/*/fd/* as root.
msw has answered the question correctly but if you want to file the list of open processes, the lsof command will give it to you.
Can I rename a folder in Perforce from //depot/FooBar/ to //depot/Foobar/?
I've tried this by renaming from //depot/FooBar/ to //depot/Temp/ to //Depot/Foobar/ but the end result ends up the same as //depot/FooBar/.
Once it is in Perforce, the case remains set. As mentioned by Johan you can obliterate, set the name up correctly, and add it in again. However, there is a slight gotcha....
If anyone else (running Windows) has already synced the wrong-cased version, then when they sync again the right one, it will not change the case on their PC. This is a peculiarity of the Windows file system acknowledging case but still being fundamentally case-independent.
If a number of users have synced, and it is not convenient to get them to remove-from-client too (and blasting the folders from their machines), then you can resort to a dark and dirty Perforce technique called "Checkpoint surgery". It's not for the fainthearted, but you do this:
Stop your server, take a checkpoint.
Using your favourite text editor that can handle multi-megabyte files, search & replace all occurances of the old case name with the new. You could of course use a script too.
Replay your checkpoint file to recreate the Perforce database meta data.
Restart your server.
This will affect all user client specs transparently, and so when they sync they will get the right case as if by magic.
It sounds hairy, but I've had to do it before and as long as you take care, backup, do a trial run etc, then all should be OK.
Maybe not needed anymore, but here's the official Perforce HowTo about changing file cases on Windows and Unix: http://answers.perforce.com/articles/KB/3448/?q=change+file+case
I'm not sure about directories, but we've had this problem with files. To fix it, we have to delete the file, submit that change, then p4 add the file with the correct case and submit the second change. Once that's done, unix users who have sync'ed the incorrect-case file have to p4 sync, then physically delete the file (because p4 won't update the case) and then p4 sync -f the file.
Our server is on Windows, so that might make a difference.
I guess it treats files and folders the same.
For files:
It depends (on whether you have a Windows or Unix server). We have this problem with our Windows perforce server (which versions our Java code), where very occasionally someone will check in a file with a case problem (this then causes compile errors because it's Java). The only way to fix this is to obliterate the file and resubmit it with the correct case.
I think you should remove the Perforce Cache, so that your modification can be shown.
You can rename with ABC rename to abc_TMP, then abc_TMP rename to abc, then clear cache.
Setps to clear cache:
Open windows user home folder (on windows7 ==> C:\Users\)
Locate the folder called ".p4qt"
Rename the folder to "old.p4qt"
Launch Perforce, now everything works!
NOTE: these steps will rest your default setting.
The question is over 3 years old, but I ran into an issue like this while doing a Subversion import into Perforce and figured the info I got could be useful to some. It's similar to the obliterate method, but helps you retain history. You use the duplicate command that may not have been available back then to retain the history. The process basically being:
Duplicate to temporary location.
Obliterate the location you just duplicated.
Duplicate from the temporary location to the renamed case location.
Obliterate the temporary location.
Through this you retain the history of file changes, but get them all in the new path as well. Unfortunately there will be no history of the path case change, but that seems to be unavoidable. Similar to other methods mentioned here, users will need to either manually rename the directories in their workspace or delete and re-sync to get the new path name.
Also, P4V caches the paths it shows in the tree so after doing this it may still show up as the old name. a p4 dirs command however will show the new case.