I noticed that when I created migration file with very long description in file name then it is omitted by flyway. There are no logs regarding the file, I'd expect at least some error on console.
I'm going through docs but I cannot find any mention regarding migration file name size.
I'm working on windows so maybe there are some system limitations.
If there is indeed such a limit then please reference me to proper sources.
The most likely restriction you're running up against is the description (the part of the filename missing the V1__ version and .sql suffix) goes into a fixed size field in the history table. That insert may fail if the file name is too long. What file name do you not see?
If you run with full debug -X do you see any errors?
Related
Anyone seen this error before?
"ERROR: User does not have appropriate authorization level for file WORK.SASMACR.CATALOG"
Occasionally, our batch jobs stops with this error. I don't understand how a file in work should not be writeable?
Thanks,
Stig
After I disabled antivirus (Sophos) online scanning for the work folder and *.sas7bcat files the error seem to have gone away.
According to this http://support.sas.com/documentation/cdl/en/mcrolref/61885/HTML/default/viewer.htm#a001328775.htm , macro catalogs are usually read-only, except while macros are being compiled or updated. Perhaps this answers the "why this file in work folder is not writable" part of your question.
Can we add metadata to unlink/remove a file after x-time automatically. That is system automatically removes that file, if it finds that particular metadata attached with that file
Note- file can be present at any location, and user may move that file anywhere on their system, but based on that metadata file should get deleted(i.e system should call unlink/remove) for that file.
Is there a cocoa/objective-c/c++ api to set such metadata/attributes of a file?
The main point is i am creating an application through which i am providing some trial files to the user, and those files are also usable by other application which recognises them. After trial expiry, i want to delete those files, but user can always move my files to a different location and use them forever, how to protect those files from permanent use?
No, there is no built-in mechanism to auto-delete a file based on some metadata.
You could add the feature yourself, with an accompanying agent that would trawl for files with the metadata and delete them when the time came.
If you are doing this for good housekeeping you can follow #Petesh answer.
If you are doing this because you really want those files gone then no. The user could move the file to a USB stick and remove it, or edit the metadata, etc.
Your earlier question "Completely restricting all types of access to a folder" seems to addressing the same issue and the suggestions are the same as given there - use encryption or implement your own file system.
E.g. have a special "trial file" format which is the same as the ordinary format - which is readable by other apps - but encrypted and includes an expiry date. Your app then decrypts the file, checks the date, and either does its thing or reports to the user the file is out of date.
The system isn't unbreakable, but its a reasonable barrier - easy for you to do, too hard for the average user to break.
I got a project to improve a WWW-store which is based on OsCommerce. I have no experience on it so how can I configure it as payment modules gives a warning:
include(/var/www/vhosts/shop.fi/httpdocs/includes/languages/english/modules/payment/banktransfer.php) [function.include]: failed to open stream: No such file or directory in /var/www/vhosts/shop.fi/httpdocs/admin/modules.php on line 128
And backups won't either work as it says
Error: Backup directory is not writeable.
These two problems should really be very easy ones. For the first one, you probably just need to put the "banktransfer.php" language file in its directory, under /languages/english/modules/payment as you can see in your error notice. If you don't have a backup of this file, you can always upload the default file from a fresh OSC copy and change the labels in the file as you need, if so.
For the backup directory error, is really the same problem. I obviously don't know what backup directory you had, but you could just have a look in the admin or try to find it via FTP, is probably something like "backup", "backups" or the translation in Finnish? Then just change the permissions via FTP, probably to 777 (or Read + Write + Execute by Others).
The debug settings are stored in a .user file which should not be added to source control. However this file does contain useful information. Now I need to set each time I trying to build a fresh checkout.
Is there some workaround to make this less cumbersome?
Edit: It contains the debug launch parameters. This is often not really a per-user setting. The default is $(TargetPath), but I often set it to something like $(SolutionDir)TestApp\test.exe with a few command line arguments. So it isn't a local machine setting per se.
Well, I believe this file is human readable (xml format I think?), so you could create a template that is put into source control that everyone would check out, for instance settings.user.template. Each developer would than copy this to settings.user or whatever the name is and modify the contents to be what they need it to be.
Its been a while since I've looked at that file, but I've done similar things to this numerous times.
Set the debug launch parameters in a batch file, add the batch file to source control. Set the startup path in VS to startup.bat $(TargetPath).
I wish to store a single variable in my application that will be saved between runs. This will be a version number that will be used to trigger an update option and so will change only rarely.
Does anyone have suggestions on the best way of implementing this? Considering it's such a simple requirement I am interested in the simplest solution.
Thanks!
Normally, that sort of information will be held in a constant (not a variable) in the binary, and the binary will contact an external site to find out whether there is a more recent version of the software. When it downloads the new, the newly downloaded file will have a new constant embedded in it.
Alternatively, you could keep the information in some sort of file in the file system. I'm not familiar with the Symbian environment, but something similar most likely exists.
It has already been mentioned, so I am going to elaborate on it. Create a file in your project directory that will contain the version number. Make that file a part of final SIS file by adding a line about it in the PKG file---for example, put a line in the PKG file to tell the installer to copy the file to a place like c:\System\Apps\${AppName}\${filename} on the device. Within code, read the version number from that file. The advantage you will have from doing it this way is that when you update your code and edit the file in your project directory and recreate an updated SIS file, on updating the SIS on the device, the version file will automatically get replaced with the current one.