FileSieve 4

Sorry guys, but I can no longer offer my software for free - it’s gotten me no-where the last two decades, so...

no task description

no task description

no task description

no task description

Closing the Method/Modifer selection window with the titlebar close button results in a Disposed error when opening the window again.

There’s something very wrong with the whole Profile and Method/Modifier interaction in regards to the currently active settings.

Profile.Active.ActiveMethod.MethodSettings contains the correct settings
Profile.Active.ActiveMethod.Method.Settings contains the INCORRECT settings

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.

Expand the Source Item Editor to provide more fine-grained control over which items should both be included and excluded during scanning.

This’ll require a redesign of the editor.

Let’s face it: XML is horrible, and .NET’s implementation is a cause of numerous headaches.

XML is being dropped, so remove all traces of XML.

no task description

no task description

no task description

Test with the root of a drive, and a huge amount of *Source Items* and literally millions of files.

This allows FileSieve to check the version of the *Registered* plugin to see if it is the expected version; if it isn’t, FileSieve should prompt the user to update their license.

If the user doesn’t update their license, they may miss out on additional functionality their license unlocks.

no task description

no task description

no task description

no task description

no task description

Now that the tracker at Bugs.BootBlock.co.uk is live and has replaced FileSieve @ Trello, all references to Trello should be replaced with the new tracker.

Although, saying that, I’m not sure the sub-domain should necessarily be called Bugs as it’s more than that. Maybe rename it to Tracker.

See forum post.

This...

\%GENRE_FIRST%\%ALBUM_ARTIST_FIRST%\%ALBUM_TITLE%\

becomes this...

Y:\Music\ContemporaryTedCrillyA Song for Europe\FileName.mp3

Initial thoughts are that FileSieve is stripping slashes due to - possibly - a call to MakeFilesystemLegal().

Selecting the EXIF plugin within the Methods window causes the following exception:

• Error: The method or operation is not implemented
• At: Method.Exif.Plugin.get_Capabilities()

For the end user, this exception can be safely ignored while a fix is being prepared.

This bug was submitted via the Pique exception service; big thanks to the user that reported this!

When the active plugin has opened a window (eg. the EXIF/Tag plugins have their own EXIF/Tag viewers) and the active plugin is changed to another plugin, the window belonging to the former plugin stays open. This results in a dangling reference and eventually an exception when the user/application closes that window.

Plugins that open any child windows will need to close those windows when the plugin becomes inactive.

Child windows are already closed on SettingsEditor.Closing(), but ideally an event should be added to SettingsEditor so plugins know when they’ve been deselected so they can take appropriate action - such as closing aforementioned child windows.

While the Find Replace method is selected within the Methods window, clicking on Verify Settings causes the following exception:

• Error: Object reference not set to an instance of an object
• At: FS.Main.Forms.Methods.Verify(Boolean onlyShowErrors)

—-
This bug was submitted via the Pique exception service; big thanks to the user that reported this!

Using the Profile Manager, clicking on New but keeping the default New Profile name and hitting enter doesn’t rename the Guid-based on-disk file to “New Profile” and instead keeps the generated Guid.

Discovered while implementing the new Trigger system.

Exception: Value of ‘720’ is not valid for ‘Value’. ‘Value’ should be between ‘minimum’ and ‘maximum’. Parameter name: Value

at System.Windows.Forms.ProgressBar.set_Value(Int32 value)
at FS.Main.Core.Results.ResultsControls.UpdateProgressBar()

When there are multiple profiles defined, it appears the Method settings for one (maybe the first) profile is loaded despite another profile having been auto-selected at during startup.

Removing the extra profile results in the Method settings being correctly loaded for the profile.

Further testing is required to see if Modifiers - and anything else - are affected.

EDIT: Can’t seem to delete this task, so instead see the replacement task  FS#281 .

Message: Object reference not set to an instance of an object.

Runtime: 2485 seconds

at FS.Main.Core.Process.set_IsPaused(Boolean value)
at FS.Main.Core.Process.Stop()
at FS.Main.Forms.Main.cmdProcessing_Stop_Click(Object sender, EventArgs e)
at System.Windows.Forms.Control.OnClick(EventArgs e)
at System.Windows.Forms.Button.OnClick(EventArgs e)
at System.Windows.Forms.Button.OnMouseUp(MouseEventArgs mevent)
at System.Windows.Forms.Control.WmMouseUp(Message m, MouseButtons button, Int32 clicks)
at System.Windows.Forms.Control.WndProc(Message m)
at System.Windows.Forms.ButtonBase.WndProc(Message m)
at System.Windows.Forms.Button.WndProc(Message m)
at System.Windows.Forms.Control.ControlNativeWindow.OnMessage(Message m)
at System.Windows.Forms.Control.ControlNativeWindow.WndProc(Message m)
at System.Windows.Forms.NativeWindow.Callback(IntPtr hWnd, Int32 msg, IntPtr wparam, IntPtr lparam)

Submitted via the Pique exception service; thanks to the submitter!

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).

Being able to effectively - not literally - “emulate” the interface events should cover everyone’s needs.

Also being able to run various commands in one call would be very convenient, if not essential.

Add support for Profile Triggering.

A Trigger allows the monitoring of certain events; when an event has been detected, the Trigger can then automatically start a Profile processing.

For example, the DateTime Trigger would auto-start a Profile based on a date and time - without any manual user interaction.

Each Source Item should have a setting that tells FS that the path must exist before processing can begin, or not, and Default. Default will instead use the Profile’s setting of Ensure Exists or not.

Have the Status ListViewItem within the Results listview tell the user to check the log should an error occur.

no task description

no task description

Convert string concats to $”” format, remove un-required namespace prefixes, etc.

In general, improve code.

no task description

no task description

no task description

no task description

Match against a filename and put it into a custom-named directory.

no task description