Accessing the clipboard in a Firemonkey application

 Delphi  Comments Off on Accessing the clipboard in a Firemonkey application
Feb 282015
 

It just took me quite a while to find this information so I’ll put it here for future reference.

A Firemonkey application can not just access the clipboard, it needs to ask the platform whether it actually has one, then get the service interface and use that.

uses
  Fmx.Platform;

[...]
function TryGetClipboardService(out _clp: IFMXClipboardService): boolean;
begin
  Result := TPlatformServices.Current.SupportsPlatformService(IFMXClipboardService);
  if Result then
    _clp := IFMXClipboardService(TPlatformServices.Current.GetPlatformService(IFMXClipboardService));
end;

procedure StringToClipboard(const _s: string);
var
  clp: IFMXClipboardService;
begin
  if TryGetClipboardService(clp) then
    clp.SetClipboard(_s);
end;

procedure StringFromClipboard(out _s: string);
var
  clp: IFMXClipboardService;
  Value: TValue;
  s: string;
begin
  if TryGetClipboardService(clp) then begin
    Value := clp.GetClipboard;
    if not Value.TryAsType(_s) then
      _s := '';
  end;
end;

(This is for Delphi XE7.)

TEdit and TMemo have got a CopyToClipboard and PasteFromClipboard method. (Which begs the question: Why not implement a generic function for reading and writing a string rather than methods for two controls? I was tempted to use the Visual Basic solution: Put a hidden control on the form and use its methods. Bad memories awake …)

 Posted by on 2015-02-28 at 21:24

Updated dzEditorLineEndsFix

 Delphi  Comments Off on Updated dzEditorLineEndsFix
Feb 282015
 

I have just updated dzEditorLineEndsFix to address a small problem: The tool can be too fast so the file is already gone when Delphi tries to access it. It now waits 200 ms after detecting the file creation before moving it. This should solve the issue.

It’s available for download from the dzEditorLineEndsFix page on SourceForge.

 Posted by on 2015-02-28 at 14:33

On expiring Dirvish images

 Linux  Comments Off on On expiring Dirvish images
Feb 162015
 

Dirvish is a backup solution for Linux (and probably other unixoid OSes). I use it to make a daily backup of one server to a different server located in a different building (it’s not the only backup solution we use but the most convenient one because we can access these files easily). Once set up, it runs automatically and I have configured it to send me an email with the result of the backup and the remaining free hard disk space. I’m not the only one who does that.

The backup server has multiple 2 tb disks mounted as a single btrfs volume, so the resulting disk space is huge. The backup has run flawlessly for over a year until now it started running out of space. So now is the first time I have actually to think about expiring old backups. (Bad Thomas, you should have given that a little bit more thought from the beginning.)

The way Dirvish handles expiry is like this:

You specify a default expiry rule and optionally more detailed expiry rules in either /etc/dirvish/master.conf or in the vault’s default.conf file. If you don’t change anything, most Dirvish installations will set the default to +1 year:

expire-default: +1 year

All this will do is add an Expire entry to the summary file of each image. To actually expire anything you must call dirvish-expire, but that call is usually added to cron automatically by the dirvish package via the /etc/dirvish/dirvish-cron shell script:

# other stuff ...
/usr/sbin/dirvish-expire --quiet && /usr/sbin/dirvish-runall --quiet

Now, expiring every image after one year is probably not the best backup strategy. You usually want to keep one copy every week, every month and every year for a longer period, maybe even forever. So more complex rules are required and must be added to either /etc/dirvish/master.conf or default.conf of an individual vault. I opted for keeping Friday backups forever and deleting everything else after 9 months, so the configuration looks like this:

expire-default: +9 months

# keep Friday backups forever
# (for everything else we use the default from above)
expire-rule:
#       MIN    HR      DOM     MON     DOW     STRFTIME_FMT
        *       *       *       *       fri     never

The rules follow crontab format, so the line above means:

  • ignore the minute
  • ignore the hour
  • ignore the day of the month
  • ignore the month
  • only for Friday

Here is a good explanation about how these rules work.

Now, since all this does is adding an entry to the summary file of each image, I have a problem: This takes care of all future backups, but all existing images were created with an expire-default of +1 year, so they contain corresponding entries like this:

Image: 2014-02-21_12-00
Reference: 2014-02-20_12-00
Image-now: 2014-02-21 12:00:02
Expire: +1 year == 2015-02-21 12:00:02

So the image was taken on 21 FEB 2014 and will be expired on 21 FEB 2015. That is a Friday backup, so I want it to be kept forever. Other images also have an expire entry of +1 year but I have to free up some disk space and therefore want to expire them after 9 months already.

What this means is that I need to change the expire entry in the summary files. All two hundred and something of them. That’s not something you want to do by hand because it’s boring and error prone.

I could probably write a shell script (but since I rarely do that it would also be quite error prone) or a Perl script (same problem even though I have got more practice with that). So I’ll write a Delphi program and access the files via a Samba share.

 Posted by on 2015-02-16 at 12:09