I'm posting this rather odd issue here in the remote chance that someone has come across this before, or possibly just has an idea or two about what I could try or check next because I'm stumped.
Summary: SQL 2008 SSIS package tasks that attempt to create files with .zip extension fail with
"Access to the path is denied"
Detail: This first occurred in a test environment with a package that works fine in Dev (and Prod). The part that makes this problem odd is that it is all about the File Extension, not security. I mention this now to curb replies about checking the security (SSIS Account, Directory Level permissions etc.) :- it's not that, 100%.
So, I've built an SSIS package as a proof of behavior, that takes 3 files (a.txt, b.txt, c.txt) and respectively for
(a) uses CozyRoc Zip to Create a Zip,
(b) uses a script task to create a .zip (using GZipStream - I know this creates a GZIP not a ZIP but bear with me...) and
(c) native SSIS File System Task copies the file from c.txt to c.zip (yes, creating a .zip file that is not really a zip file).
All Three fail with the above message - the .ZIP files are created for (a) and (b), but remain at 0 length. (For (c) just the error message).
Now, I edit the SSIS package and change the extensions of the destinations (to .ZOP or .ZIP2 or .GZ or .ANYTHING), and all 3 work perfectly. And this is obviously how I know that it's the .ZIP extension not a "normal" security issue.
So I've initially assumed this is a one-off on this test server because it was the only place it happens, but I've found another box (build rehearsal) on which exactly the same problem exists. I've tried associating .ZIP with various different programs (Windows Explorer, WinZip, 7Zip, WinRar & "no program") and nothing works, and I've googled the problem to death with no luck yet.
I've tried creating .ZIP files with the various installed archive programs using their GUIs and they all work fine. Existing .ZIP files can be unzipped using CozyRoc. Existing .GZ (GZIP) files renamed to .ZIP can be unzipped using the script GZipStream decompress. And I can rename files to and from .ZIP using SSIS or Explorer/CMD. It's just SSIS (specifically SSIS) creating a file with extension .ZIP (specifically .ZIP) throws this error.
I'm starting to suspect it might have something to do with SSIS thinking that .ZIP is an archive "folder" not a ".ZIP File" but I don't know where to go with this idea, proving it or fixing it.
Any ideas at all? - at my wits end!!
Thanks in advance
P.S. The "obvious" answer of using .ZIP2 and renaming is not an option, there are (literally) hundreds of packages running in production that create .ZIP files and packages need to move from Test to Prod without modification. I really need a solution, not a workaround, in this instance if there is one.
This turned out to be a RedGate tool (HyperBac) having a file association with .ZIP extension files (amongst others). Hyperbac's monitoring of .ZIP files appears to have clashed with SSIS's attempt to write to the .ZIP file, as procmon reported shared file access violations, causing a spurious ACCESS DENIED error to be reported by the package.
Since use of the tool is necessary on our environments, I was able to solve the problem by deleting the .ZIP association using the GUI ("Hyperbac Configuration Manager" > "Extensions" > Ext=.ZIP, Delete)
Related
I created an SSIS package that extracts two files from a .zip file, imports data from them and then attempts to delete the files that were extracted.
The package works, data is imported and all tasks report success. However the File System Tasks that attempt to delete the files don't delete them, even though they report success.
I use the CozyRoc Zip Task to extract the files. When I remove the Zip Task, the File System Tasks actually do delete the files. I'm not certain that CozyRoc is causing the problem, but the existence of that task may be causing other issues with the package.
Can anyone help me figure out how to reliably delete the files?
Do I need to put in some sort of pause after the Data Flow Tasks to allow them to release whatever locks they might have on the files?
Is there a way to view the DOS commands that the File System tasks use at run time, to verify that they are actually attempting to delete the correct files?
Thank You,
Robbie
Control Flow:
Details:
Visual Studio 2019 v16.11.3
File Names are from Flat File Connection Managers (See image below).
Flat File Connection Managers use Expressions to set their connection strings.
The same connection managers are used to import the data, so I presume that they accurately refer to the correct files and their correct locations.
File System Task Editor for one of the delete tasks:
I want to know if it is possible to restore my database without dump.
In fact, I had a problem with mysql on my debian 9 server. I uninstall debian and reinstate it. I lost everything but before uninstall debian, I saved ib_logfile0, ib_logfile1 and ibdata1 files and the database folder with the database name. There files and folder was located in /var/lib/mysql
I already tried to copy and paste the files and the folder on my new debian but it doesn't work...
Is it possible to restore the database with this 3 files and this folder (on the folder, there is .frm and .ibd files) ?
If you have the entire folder, then you effectively have the entire dataset. The two things that are elsewhere:
The MySQL code -- It would be wise to install the same version 5.xx.yy.
The config file(s) -- /etc/my.cnf (or wherever). You may have to reconstruct it. The one tricky setting (if you had changed it) is innodb_log_file_size.
I am not sure if there are other critical files in the directory other than the 3 files you mentioned.
Give it a try.
I have an MSI file that contains several .sql script files, can anyone tell me if it is possible to extract these file and look at the content. I tried using orca to export the ISSQLScriptFile table, but the files were exported as .sql.ibd, which is useless.
Thank you!
I haven't looked at this in a long time but as I recall it's all encrypted.
https://community.flexerasoftware.com/showthread.php?188927-Extract-packed-script-sql-from-msi
"For security, the script is encrypted and then stored in the MSI package."
Someone then mentions that you can intercept the SQL files from a temp directory while the installer is running.
MichaelU could weigh in if this is still true and if there are any other work arounds.
Assuming that the files are inside the MSI file in the sense of being in the internal CAB file, then do an "administrative" install, which is not an install at all. A typical command would be:
msiexec /a [path to msi file] TARGETDIR=[path to a folder where the files will go]
It extracts all the separate files to that location.
We've run into a strange issue. We have some SSIS 2008 packages that had been working fine for quite a while. As part of the work flow they copy files to a backup folder, and then delete the original file. (No, I don't know why they didn't just make it a File Move task.) Suddenly, the delete task has stopped working. It's not just our packages either, it's the packages of a different group on a different SSIS server. Same target folders though.
The server team has gone over the folder permissions, the account the jobs run under have full access. And, if it was an access issue, how could we move the file but not delete it?
We finally found the answer. The file server we're using is Linux based. It is case sensitive, but doesn't throw an error if you use the wrong case. Was a very tough issue for us to track down.
Windows 2008 R2 - Kernel (System Process PID=4) is locking files and folders for a long time.
For example when deleting a file, the file may remain locked for 1 minute or more and only after that be deleted.
On another occasions I encountered files or folders I could not delete. ProcMon showed that the System Process was holding a handle to those resources for a couple of minutes and then released them
None of the resources I mentioned were system resources, only files and folders installed be me and handled by my applications.
As Dani has already mentioned in the comment:
It's a bug in Windows 7 and likely in Windows Server 2008 (possibly 64bit versions only). It surfaces when you disable Application Experience service.
Re-enabling this service has fixed this problem for me.
A bit more info here as to why it's causing a problem.
List of other SO questions which seem to be related:
Visual Studio output file permissions?
Under which circumstances does the System process (PID 4) retain an open file handle?
Files accessed through a share will be locked by the system process (PID 4).
Try opening compmgmt.msc -> System Tools -> Shared Folders -> Open Files to see if the locked file is listed there
See also the sysinternals forum for a way to replicate this.
Not all applications lock files when they are opened, Excel however does...
In my case, it was fixed by a simple command in the command line:
net session /delete
I hope that helps.
Hope this helps others.
open windows run and lauch mmc.exe
File -> Add or Remove Snap-ins --> Shared Folders --> localcomputer
Select Open Files scroll down to the directory or file and right click to close.
You can also get the username that has the lock and go to sessions and right click --> close session.
In my case it was MacOS 10.13 holding file locks open...
https://support.apple.com/en-us/HT208209
I had this issue when trying to rename a folder. I had to stop the server service while performing the rename. Just restarting didn't help, as the system process re-locked the folder as soon as the server service restarted.
Make this and resolve the problem:
Go to Services and activate Application Experience.
Tried all these...
Even copying the file, deleting the original, renaming copy to original name (all on server) would immediately tell me the user had it locked.
In the end -
used Unlocker to clear the file locks.
Copied the file OFF THE SERVER to a desktop.
Deleted the original file off the server.
Changed the filename of the copy on the desktop.
Renamed it back to the original name on the desktop.
Put the file back into the original location ON THE SERVER.
HTH, YMMV... :)
Had this issue just now whilst trying to replicate data to a new file server (both source & destination servers running Windows 2008 R2).
PID 4 was found locking the file (using procexp as above), but Application Experience has never been installed on either server & the file was not shown in the list of open files.
Fortunately we use scheduled shadow copies on this server (to enable users to self-serve most file recoveries). I just used the Previous Versions option (available through Properties of the containing folder), selected the most recent copy of the file & copied it to somewhere else, then deleted and replaced the problem file.
You might need to delete the containing folder to delete the file - which could be a problem if lots of files in use obviously (this wasn't an issue for me given this was the only file in the folder).
For a one-off issue like I had (single locked file for the whole server drive), this worked without any disruption to the server or users.
Given you are talking about a server & that Shadow Copies are using VSS - you should be able to recover the locked file from your backups (presumably you have these) if you don't use Shadow Copies. Otherwise there are some useful utils like ShadowSpawn (https://github.com/candera/shadowspawn) around that might help.