Tracker.BootBlock.co.uk ::

FS#345: UNC paths cannot be specified via the command-line

Joseph Cox — Thu, 31 May 2018 09:33:01 +0000

For example, the following path:

\\server\path\

The first slash of the two leading slashes is being treated as a switch character and consequently is being stripped from the UNC, so textForge cannot open it correctly.

There is now a check within the BiQubic.Suite.Core.AppFramework library that now determines if a command-line parameter starts with a double-slash; if it does, then it is treated as an unswitched parameter.

FS#343: Source Item - Maximum File size reverts back to 0

Joseph Cox — Mon, 28 May 2018 18:11:22 +0000

The default value of the MaximumFilesize property was incorrectly set to 0 which resulted in the property’s value being set back to 0 if it was ever changed to -1 (minus one meaning that no max size check should be performed).

FS#332: Add 'Added Items' to Progress

Joseph Cox — Wed, 28 Feb 2018 18:43:23 +0000

When re-running the same profile against a folder that has already been processed, it would show the number of files that has been added in the last run.

Suggested by Olivier C.

FS#331: Overwrite Rules Options

Joseph Cox — Tue, 27 Feb 2018 13:06:13 +0000

There will be additional settings available that apply to the overwrite rules, specifically how FileSieve should determine what constitutes an ‘identical’ file. For example, compare just file names; or file names, date stamps; or hashing; or all of those.

The Destination area of FileSieve simply isn’t big enough to contain these extra options - and it would look like a mess even if it was - so a new window will be added to contain them.

FS#330: Overwrite Rules only generating a single rename mask

Joseph Cox — Tue, 27 Feb 2018 10:06:06 +0000

When FileSieve (FS) encounters a file that already exists in the destination and the user has set some overwrite rules, FS generates a filename based on the entered Rename Mask and tests to see if that exists. If it does, it then generates another name (based on the # code (%file_number% in 4.36); that hash symbol represents a number that is incremented each time an on-disk collision is detected) and tests that.

Due to a bug in 4.35 and earlier (unknown at which point the bug was introduced but it may have been due to some major changes to the engine code - specifically the Prescanning step - so FS can gather additional metadata on files to give plugins more control and flexibility), the first attempt at generating a filename was always successful regardless of if that file existed on-disk.

The reason for this is that it was using the wrong path to check for the file’s existence.

Fixed in 4.36.

FS#329: Added Items

Joseph Cox — Tue, 27 Feb 2018 09:10:08 +0000

In the Step 5 Processing: Add a line: ‘Added Items’. When re-running the same profile against a folder that has already been processed, it would show the number of files that have been added in the last run.

Thanks to Olivier C. for suggesting

FS#328: Another Tooltips pass

Joseph Cox — Mon, 26 Feb 2018 09:39:28 +0000

Make another pass over the entire FileSieve interface to ensure tooltips are present and comprehensive.

FS#327: Additional Overwrite Rules Editor codes

Joseph Cox — Mon, 26 Feb 2018 09:31:34 +0000

Add additional overwrite codes to the Overwrite Rules Editor, such as %created_year% (original file’s created date year), %created_month%, and so on.

When the Overwrite Rules Editor was originally implemented, FileSieve didn’t collect comprehensive metadata on the files it processed, such as file dates and the like. It’s been a while since metadata collection was added, so the rules editor needs to be updated to support that information.

IMPORTANT CHANGES TO SOME EXISTING CODES

 %file% is now %file_name%
 %ext% is now %file_ext%
 # is now %file_number%

Older codes are automatically upgraded to the new format.

FS#326: Simplified Overwrite Rule Yes/No-style option

Joseph Cox — Sat, 24 Feb 2018 11:05:56 +0000

The Overwrite Rules Editor may be a bit too complex for new users to understand, especially if all they want to do is tell FileSieve that it should rename files (current default behaviour) or just ignored already-existing files.

FS#325: Preserve datestamps for processed files

Joseph Cox — Thu, 22 Feb 2018 14:54:01 +0000

When files are copied or moved to their destination, their date stamps (Created, Modified, Written) are changed to the date and time of when FileSieve processed them.

This may sound like a bug (and initially did to me when this was reported), but the files are that copied/moved are entirely new files - not the originals that are being processed. FileSieve uses its own I/O code that supports buffer optimisation, async I/O, and operation progress; so it isn’t manually setting the date/time stamps like the OS does when it itself performs the copy or move.

This task entry is to add a new feature to FileSieve that preserves those date and time stamps.

I’m somewhat undecided whether this should be a core FileSieve setting or implemented as a Modifier. FileSieve settings aren’t configurable on a per-Profile basis and so will more than likely be a Modifier. The only potential issue with it being a Modifier is that FileSieve doesn’t set “default” Modifiers; coupling a FileSieve setting with the Modifier itself will provide user convenience in-spite of that fact FileSieve will become (loosely) coupled with a plugin.

Thanks to Olivier C. for reporting