File Finder + error detection/notification shortcomings

tullik

Sorry, we encountered an error while displaying this content. If you're a user, please try again later. If you're an administrator, take a look in your Flarum log files for more information.

tullik

File Finder error detection/notification behavior with specific error producing conditions

Files with open handles:

Please see first post in this thread.

Read only files:

Tests 1 through 4, 6, 10 through 13, and 15 were performed against three read only files. The red observations are either outright bugs or inconsistentcies with open handle results that may indicate possible bugs either here or there ...

These tests were done on my desktop (see signature line).

Test 1 -- Remove button and backup=yes

a. -- "Error! Failed to remove ..." message for each of the 3 files.

b. -- the 3 files stayed on the list

c. -- rescan -- the files still existed

d. -- full backup occured

Test 2 -- Remove button and backup=no

a. -- same behavior as for files with open handles -- no problem

Test 3 -- More functions...Copy to...

a. -- function succeeded, no errors

b. -- the 3 files stayed on the list -- no problem

Test 4 -- More functions...Move to...

a. -- "Are you sure you want to move the read-only file ..." message for each of the 3 files -- then "Done!" popped up.

b. -- the 3 files dropped from the list -- no problem

c. -- did a rescan

Test 6 -- More functions...Mass rename... (Change requested: set ---> setx)

a. -- function succeeded, no errors

b. -- the 3 files on the list changed to show the new name

c. -- the 3 files stayed on the list -- no problem

Test 10 -- More functions...Wipe and backup=yes

a. -- no messages

b. -- the 3 files dropped from the list

c. -- rescan -- one file listed on the prior list still existed and was unchanged (per duplicate finder) -- a bug

d. -- there was no backup (not even an index.dat) -- a bug

Test 11 -- More functions...Wipe and backup=no

a. -- no messages

b. -- the 3 files dropped from the list

c. -- rescan -- one file listed on the prior list still existed and was unchanged (per duplicate finder) -- a bug

d. -- there was no backup (as expected)

Test 12 -- More functions...Move to recycle bin and backup=yes

a. -- no messages

b. -- the 3 files dropped from the list

c. -- rescan -- the files were gone

d. -- there was no backup (not even an index.dat) -- a bug

e. -- the files were not in the recycle bin -- a bug

Test 13 -- More functions...Move to recycle bin and backup=no

a. -- no messages

b. -- the 3 files dropped from the list

c. -- rescan -- the files were gone

d. -- there was no backup (as expected)

e. -- the files were in the recycle bin -- no problem

Test 15 (2) -- only one file selected -- More functions...Split... (1.44 MB 3.5"floppy -- Desktop target -- delete after split=yes -- Name policy-Part -- Simulation...did not show an empty list

a. -- Start button instantly produced the "Done!" pop-up

b. -- warning message about no backup -- the file stayed on the list

c. -- one "split" file appeared on the Desktop (too small to actually split - it was a duplicate with a new name)

d. -- there original file was not deleted -- a bug

End of File Finder tests for read only files

tullik

File Finder error detection/notification behavior with specific error producing conditions

Files with open handles:

Please see first post in this thread.

Read only files:

Please see second post in this thread.

Hidden files:

Tests 1 and 2 were performed against three hidden files. Since the the hidden attribute did not trigger any errors, no other tests were done.

These tests were done on my desktop (see signature line).

Test 1 -- Remove button and backup=yes

a. -- no messages

b. -- the 3 files dropped from the list -- no problem

c. -- rescan -- the files were gone

d. -- full backup occured

Test 2 -- Remove button and backup=no

a. -- no messages

b. -- the 3 files dropped from the list -- no problem

c. -- rescan -- the files were gone

d. -- no backup occured (expected)

End of File Finder tests for hidden files

tullik

File Finder error detection/notification behavior with specific error producing conditions ::::

Files with open handles:

Please see first post in this thread.

Read only files:

Please see second post in this thread.

Hidden files:

Please see third post in this thread.

System files:

Tests 1 and 2 were performed against three system files. Since the the system attribute did not trigger any errors, no other tests were done.

These tests were done on my desktop (see signature line).

Test 1 -- Remove button and backup=yes

a. -- no messages

b. -- the 3 files dropped from the list -- no problem

c. -- rescan -- the files were gone

d. -- full backup occured

Test 2 -- Remove button and backup=no

a. -- no messages

b. -- the 3 files dropped from the list -- no problem

c. -- rescan -- the files were gone

d. -- no backup occured (expected)

End of File Finder tests for system files

jv16

tullik wrote

Test observation summary:

Test 8 & 9 ------ "Empty" applies to directories, not files -- a bug

Actually, the Empty does apply to files - it empties the file. The Directory Tool has a similar feature that empties a directory.

All the bugs detected in this test are now fixed, thank you for reporting. The next released version contains the fixes.

In short: the File Tool now verifies access to the files about to be accessed before any action takes place, if no access is received (access denied, file in use etc) then an error message is shown and the line is not removed from the list.

These updates also apply to the Directory Tool as well.