I'm developing a SSIS Package that copies contents of specific files to a database. In this package I mak heavy use of the foreach container. Today I came across a strange behavior and have no clue whats wrong. In one of the containers I filter for "VBFA*.txt". But for some reason the container also gets triggered for a file called "VBAP.D2014211.T204008397.R000564.txt". When I change any part of that filename it doesn't trigger the container anymore. Additionally there are plenty of other files that start with "VBAP" and don't trigger the container. What could be the reason for this behavior?
Here is the enumerators implementation:
<DTS:ForEachEnumerator>
<DTS:Property DTS:Name="ObjectName">{6E07E755-700D-4D7D-9550-E08DA5B81264}
</DTS:Property>
<DTS:Property DTS:Name="DTSID">
{f0ceed84-f95c-404c-8794-2eec0155d1a6}</DTS:Property>
<DTS:Property DTS:Name="Description"></DTS:Property>
<DTS:Property DTS:Name="CreationName">DTS.ForEachFileEnumerator.2</DTS:Property>
<DTS:ObjectData>
<ForEachFileEnumeratorProperties>
<FEFEProperty Folder="\\desoswi0204vs\etldata\transfers\out\DP"/>
<FEFEProperty FileSpec="VBFA*.txt"/>
<FEFEProperty FileNameRetrievalType="0"/>
<FEFEProperty Recurse="0"/>
</ForEachFileEnumeratorProperties>
</DTS:ObjectData>
</DTS:ForEachEnumerator>
I've checked the paths contents with dir /x and the short name of my file is wrong. For the file "VBAP.D2014211.T204008397.R000564.txt" the shortname is "VBFA08~1.TXT". The full result is:
01.08.2014 11:02 1.067.169 VBFA08~1.TXT VBAP.D2014211.T204008397.R000564.txt
I have absolutely no clue, what is happening here and how to stop it. This violates every rule I've found regarding the short filename creation. I leave this as the answer for everybody else who is comming accross this beahvior, which is also the case for c# Directory.GetFiles
Related
In a mozille extension I run:
SecSess.Logger.info("ctypes test");
Components.utils.import("resource://gre/modules/ctypes.jsm");
SecSess.Logger.info("1");
this.lib = ctypes.open("libcrypto.so");
SecSess.Logger.info("2");
var a = new Uint8Array(1<<10);
SecSess.Logger.info("3");
var ptr = new ctypes.uint8_t.ptr(a.buffer);
SecSess.Logger.info("4");
Why this ugly logging after each step you might ask? Well this code fails without showing me an error. (or at least I can't find the error message)
This is printed:
ctypes test
1
2
3
So the 5th log message is never printed which means the following statement never completes:
var ptr = new ctypes.uint8_t.ptr(a.buffer);
This is a simplified version of some old code I have to work with and which I also found online as being valid. However it doesn't work. This add-on wasn't developped using the new SDK with jpm. Quite frankly I don't know how and when it was developped but I need to run some tests on it. It comes with a few source files ordered in a components and a modules directory and a chrome.manifest and install.rdf in the root. I copied these files to the extension directory of Mozilla in order for it to work. The extension executes but there seems to be a problem with ctypes. Aren't ctypes fully supported anymore or are these old style add-on no longer valid for the modern Firefox?
Regards,
Roel
I think they landed a a patch to disallow making a pointer from buffers. I'll double check.
Edit:
Ah per this: https://developer.mozilla.org/en-US/docs/Mozilla/js-ctypes/Using_js-ctypes/Working_with_ArrayBuffers, you don't have to wrap it with a ctypes.uint8_t.ptr just pass it like a.buffer to wherever you need it. :)
I have a Delphi5 application which exports a file (.pdf) and a very small metadata file to a network location. The intention is that these 2 files should be processed, and then removed, by a polling .NET application.
My approach is to
Write the metadata file with the extension '.part'
Generate the .pdf
Rename the .part file to .dat
The .NET process is looking for files with the extension '.dat' only, so I would expect there to be no conflict between the 2 reader/writers. However, the .NET process is occasionally logging the following error ...
System.IO.IOException: The process cannot access the file '\\server\Path\FileName.dat' because it is being used by another process.
(I say occasionally - we are currently testing, so when volumes increase this may become much more of an issue)
The Delphi code looks like this :
AssignFile(FTextFile, Format('%s\%s.part', [DMSPath, FullFileName]));
try
try
ReWrite(FTextFile);
Writeln(FTextFile, MetaDataString);
finally
CloseFile(FTextFile);
end;
except
raise ELogFileException.Create( LOGFILEWRITEFAILURE );
end;
Then there is a separate method which performs the following lines of code
if FindFirst(Format('%s\*.part',[DMSPath]), faAnyFile, SearchRec) = 0 then begin
repeat
OldName := Format('%s\%s',[DMSPath, SearchRec.Name]);
NewName := Format('%s\%s',[DMSPath, ChangeFileExt(SearchRec.Name, '.dat')]);
RenameFile(OldName, NewName);
until FindNext(SearchRec) <> 0;
FindClose(SearchRec);
end;
I cannot see anything inherently wrong with this code and we have a couple of remedies in mind, but I have 2 questions
Should I try a different technique to more reliably protect the '.dat' file until it is fully ready
What circumstances could be causing this?
So far there has been one suggested cause - Antivirus software.
Any suggestions as to how the file might be produced differently? Note that my application is Delphi5; I wondered if there was a newer, more 'atomic' version of the 'MoveFileA' WinApi call I could use.
In the past, we had a problem with file being locked like that. Investigation pointed to Windows' Prefetch. The file being affected were not on a network directory though.
As far as I know, Prefetch only work on process startup and/or while booting (Controlled by a registry key), so it might not apply to your current situation.
You can check the "C:\"Windows"\Prefetch\" directory. If prefetch is active, it should contains multiple *.pf files. If there is one with your executable filename, it might be worth investigating.
Personally speaking, because there are multiple files involved, I'd create a separate lock file (eg, myfile.lck) that you write first. If the polling app sees it in the folder, then it stops looking for other files. Once that file is gone, then it dives deeper. I don't know if this would solve the problem you're encountering or not, but I'd give it a try. (Files with .dat extensions are frequently created by malicious evildoers, so they can raise spurious issues through other sources, like AV software. A lock file with 0 bytes in it is generally harmless and disregarded.)
For some specific purpose, I need to install some fonts on the instances. It comes as no surprise when I choose StartUp Task to accomplish that goal. I've configured the Service Definitions as below:
<Startup>
<Task commandLine="Fonts\InstallFonts.vbs" executionContext="elevated" taskType="simple" />
</Startup>
Nothing special here. Click and run, it failed. However, if I changed the commandLine into a cmd file including just nonsense, namely "echo test", the instance would run without ado. So there must be some issue with my scripting:
Const FONTS = &H14&
Set objShell = CreateObject("Shell.Application")
Set objFolder = objShell.Namespace(CreateObject("Scripting.FileSystemObject").GetAbsolutePathName("."))
Set fontFolder = objShell.Namespace(FONTS)
Set rxTTF = New RegExp
rxTTF.IgnoreCase = True
rxTTF.Pattern = "\.ttf$"
Set fso = CreateObject("Scripting.FileSystemObject")
FOR EACH FontFile IN objFolder.Items()
IF rxTTF.Test(FontFile.Path) THEN
IF NOT fso.FileExists(fontFolder.Self.Path+"\\"+FontFile.Name) THEN
FontFile.InvokeVerb("Install")
END IF
END IF
NEXT
The script should come with no error because I've tested it either locally or on Azure via RDP.
Weirdly, when I put it in the startup, the role just won't start. The instance just keeps recycling and at last says "I'm unhealthy". Even if I deprecate the vbs into just one line of code - the first line Const FONTS = &H14&, it just won't start. Even if I wrap the invocation of the vbs into a cmd file, namely to put something like "cscript /B file.vbs", it won't run either.
So I'm concluding that there must be some issue regarding the communication between the script and the Windows Azure monitor. I'm not sure but I think the monitor might take the running script as a failed task. Besides, I'm wondering if there is any timeout for the startup task, which should be the problem though, because the script can guarantee that no UI interaction block the process.
Any idea would be greatly appreciated.
I am sure you must have but just for the sake of confirmation, have you checked that the InstallFonts.vbs file is exported with the package? I mean is the "Copy To Output Directory" is set to "Copy Always/Copy if newer"?
This is pretty much possible that it is not able to locate your file.
You need to write a cmd file as a start up task. In your cmd file, you can call the vbs file using the command line tool cscript.
Azure start up can compile only command line tools.
Oh god, I finally solved the problem.
Although the compiler does quite a good job usually, it allows to use subfolder as a source of command, I mean something like "Subfolder\command.cmd", which will not work always. I've seen examples in which people put whatever we do in cmd in commandLine property, such as "copy fileA fileB" and it really works. But as for vbs, you need to be cautious. Until now I still don't know what's under the cover, but there should be some problem with the path. And the solution is definitely simple, instead of doing the subfolder work for tidiness, just leave the command file in the root folder like most people do:
<Startup>
<Task commandLine="InstallFonts.vbs" executionContext="elevated" taskType="simple" />
</Startup>
And thank you all the same, Kunal. :)
I deployed my symfony 1.4 project from my local machine (Windows 7) to my test server (Linux Ubuntu Server).
Whenever I open this project through my browser (IE, FF...) I get an Error 500 which is most certainly caused due to an error which I get from the log/frontend_staging:
"symfony [err] {InvalidArgumentException} Unable to load "I18nHelper.php" helper in: SF_ROOT_DIR/apps/frontend/lib/helper, SF_ROOT_DIR/lib/helper, SF_ROOT_DIR/lib/vendor/symfony/lib/helper."
The File I18NHelper.php is located in SF_ROOT_DIR/lib/vendor/symfony/lib/helper, so I don't see a problem there. I already played with the naming, though some people mentioned they had trouble with the uppercase N in the Helpers name on Unix systems, but this didn´t solve my problem at all.
It's a very nasty little thing:
Use <?php use_helper('I18N'); ?> instead of <?php use_helper('I18n'); ?> (Mind the upper case of the last 'n').
Linux is case-sensitive, unlike Windows.
You have misspelled the helper's name The last "N" should be uppercase.
In templates it should look like:
<?php use_helper('I18N'); ?>
If you are modifying the settings.yml it should look like:
standard_helpers: [Partial, Cache, I18N]
You have to keep in mind that symfony YAML configuration files are cached as php files. If you don't clean your cache, your changes won't be applied (depending on the environment of course). Try using:
php symfony cc
from command line, it should fix it.
Delphi 2007 on windows 7 just does nothing on the saveDialog.Execute call. I have seen another person mention this a few weeks back but it was with Borland c++.
See the thread "TOpenDialog.Execute not working " on embarcadero newsgroups.
Problem there was resolved by deleting the executable name from
"HKLM\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Image File Execution Options"
I got the same problem (savedialog not working) in windows XP.
After lots of unsuccessful attempts according to the voluminous exchanges in the embarcadero group you mention (https://forums.embarcadero.com/thread.jspa?messageID=196950&tstart=0#196950).
I found what the reason was : the initial file dir and filename of the Savedialog12 were bad, contradicting each other, the filename containing the fullpath of the last file I had opened (I had thought it was smart to prepare the saving of the file I had opened last; unfortunately what I had put in the initialdir was equal to what I had put in the filename !)
The problem was already solved by clearing both fields of the save dialog.
Further, my initial goal to prepare the saving was reached by putting valid values in the involved fields :
SaveDialog1.FileName:=ExtractFileName(Opendialog1.Filename);
SaveDialog1.InitialFileDir:=ExtractFilePath(Opendialog1.Filename);