Work at SourceForge, help us to make it a better place! We have an immediate need for a Support Technician in our San Francisco or Denver office.

Close

#7 strip common path doesn't strip ".\"

open
Tom Bramer
5
2012-03-18
2012-03-18
Sean Echevarria
No

I loaded a list into the Advanced Processing dialog. The contents of the list file is a single line:
.,desktop.ini;thumb*.db;,1,1

The list directory value in the entry is simply '.' - I made that change manually in my saved list so that I could use the same list in multiple directories or drives.

The file list is processed as expected and all files are listed in directory ".\*".

When I save the results, I am prompted "since the program options are set to use relative paths for hash entries, would you like to automatically strip the common path between each entry and the newly saved file" as expected. I answer yes.

However the ".\" is not removed from any of the files listed. I would expect the output file to be the same as if I had explicitly listed the start directory rather than made it relative to the list file.

Actual result:
<entry name=".\foo\...

Expected result:
<entry name="foo\...

Discussion

  • Tom Bramer
    Tom Bramer
    2012-03-20

    Using relative paths within the advanced processing dialog is not an intended feature. It works because the common dialog for opening files (the file selection dialog when loading that CSV file) happens to set the processes' working directory as a side effect of selecting a file.

    The program does not keep track of where hash entries come from, other than the path field itself (what is displayed). The program is expecting operations that add new entries to return absolute paths. Even when the buffer is associated with a file, these operations return absolute paths, but the program subsequently corrects these paths, unless it is configured otherwise.

    The only real fix for this is to have the advanced processing dialog substitute the directory that contains the CSV file for . in the paths before handing it off to the directory recursion code. This way, if the buffer hasn't been associated with a hash file, you get absolute paths in the result, and if it is associated with a hash file, with the default configuration, those paths will get corrected so that they're relative to the hash file automatically.