One morning in a meeting, my manager asked for a list of exactly which files were in yesterday's backup. I had the log my backup script produced, three hundred and twelve lines, one full path per line, like D:\backup\2024-03-12\site\index.html. Pasted into a shared document it was a wall of directory prefixes and nobody could see what mattered. My first plan was to delete the front half of each line by hand in Notepad; I gave up before fifty lines, not because the deletion was hard but because every line needed a different number of characters removed.
Slash direction is not a style choice, it is two filesystems
Windows separates directories with a backslash \, Unix and Linux use a forward slash /. A single dataset can contain both: the log was written by a service on Windows, while attachment paths came from an object storage API. Deleting by hand with a mix of the two is risky. If you only look for the last forward slash, a path like C:\Users\name\a.txt has none, and the whole line gets handed over as a filename.
I use Filename Extractor for a simple reason: it works line by line in bulk, recognises both backslash and forward slash separators, and three hundred odd lines come back as a result in one paste. What saves time is not fewer keystrokes but not having to decide, line by line, which kind of path each one is.
One more thing worth remembering: on Linux a backslash is a legal filename character, so in /tmp/a\b.txt the backslash belongs to the name and is not a separator. The first time I did a bulk extraction I applied my Windows habits to a Linux log and every oddly named file was cut in the wrong place. When the sources are mixed, I sort the data by source first and handle each group separately.
Drive letters, UNC paths and trailing slashes are where it breaks
The first is the drive letter. In C:\Users\name\a.txt the colon sits on C:. It is not a separator, but anyone splitting by colon or by slash by hand tends to cut one step too far here and end up with a fragment like \Users\name\a.txt.
The second is a UNC path, the notation for a network share: \\server\share\a.txt. The two leading backslashes are not a doubled separator; they mark this as a shared path, and the server name and share name each take a segment after them. When I deleted by hand I removed the first backslash of \\nas01\files\report.pdf thinking it was an escape, and that line was no longer a valid path once it went into a batch script.
The third is a path with a trailing slash, such as /home/deploy/app/. That is a directory, and what follows the slash is empty. Apply the take the last segment rule and the result is an empty string rather than app. My check now is to compare the result count against the input line count and look for blank lines. A blank line means the original data contains directory-shaped paths, and that group either needs separate handling or an explicit decision that a directory name is not a filename.
Extension or not? Ask the audience first
This is the second decision in the extraction. For operations people, the extension is what makes the name useful, since access.log and access are two different things. For a report to my manager, most of the time only the base name matters, and a column full of .pdf and .zip just gets in the way. The tool lets you include or drop the extension, so I usually run both: I keep the version with extensions and hand over the one without.
Dropping the extension relies on the last dot. The exception is pack.tar.gz, where splitting at the last dot gives pack.tar and gz. My backup list had archives like that, and the no-extension version kept the .tar, which reads like irregular naming at a glance. To separate compound extensions such as .tar.gz and .tar.bz2 properly, use Filename and Extension Splitter and do not treat the plain strip-suffix result as a bug.
At the other end there are files with no extension at all. On Linux, /opt/bin/nginx and /etc/passwd have no dot, so I am extra careful with those lines when the no-extension option is on. An unclear rule will shave off part of the real name, so I pull those out and check them one by one.
Deduplication changes the count, not the format
Of the three hundred and twelve lines, turning on deduplication left two hundred and five names. The one hundred and seven missing ones are not errors, they are repeated names: index.html exists once in each of seven site directories, and app.log appears a dozen times because it rotates several times a day. Extraction keeps only what follows the last separator, and the directory in front of it is the only clue that tells those files apart, so once you deduplicate, the origin cannot be traced back.
So I turned should I deduplicate into a question I have to answer: do I want a count of distinct files, or a count of entries? For distinct files, deduplicate. For entries, do not, because whether every file was actually backed up is what the number three hundred and twelve tells you. If I need both, I save the raw result with paths before deduplicating.
| Input path (as is) | Extracted filename | Without extension | Note |
|---|---|---|---|
C:\Users\name\Documents\a.txt | a.txt | a | The colon in the drive letter is not a separator |
\\server\share\backup\report.pdf | report.pdf | report | The two leading backslashes mark a share |
/var/log/nginx/access.log | access.log | access | On Unix a backslash can be part of a name |
D:\data\archive\pack.tar.gz | pack.tar.gz | pack.tar | Split at the last dot; compound extensions need their own handling |
/home/deploy/app/ | Empty (trailing slash) | Empty | This is a directory; the name is one segment back |
/opt/bin/nginx | nginx | nginx | No extension of its own, do not shave again |
file:///data/report.pdf | report.pdf | report | The scheme prefix is treated as a directory segment |
That last row, the file:/// prefix, came up in another dataset of mine. It gets treated as one directory segment and the filename itself comes out right; but if what I want is to drop the prefix and keep a relative path, that is not an extraction job. I first remove a fixed number of characters from the left of every line with Line Operations and then extract, and the order cannot be reversed. When the prefix length varies, that positional approach fails and you have to switch to replacement.
A few questions I hit at the time
Q: Do spaces or Chinese characters in a path get cut?
No. Only the two slashes count as separators; spaces and Chinese characters are part of the name, so C:\my files\annual report 2024.docx extracts as the complete annual report 2024.docx. What really goes wrong is pasting a path into a script without quoting it, and that is a quoting problem.
Q: What if one log line contains several paths?
Bulk extraction works per line. When I hit a log with two paths on a line, I split it into one path per line first. Otherwise the separator position comes from the last path and everything in front of it is shaved off.
Q: Can it extract only files when directory names are mixed in?
I do not count on it telling them apart. A line that ends in a slash is my own signal, so I pull those out and treat them as directories, then extract the rest as files. Handing a mixed list straight over is the fastest way to get empty results.
Q: Does the order change after extraction?
Output maps to input line for line, so I can compare the two counts directly. When I check, I look at two numbers: whether the line counts match, and whether the result contains zero blank lines.
Q: Can a few hundred lines be processed in one go?
My batch of three hundred and twelve went in as a single paste, no chunking, and the check was obvious: equal line counts and it passes. With tens of thousands of lines I would worry less about processing than about checking, so at that scale I group by directory and extract section by section, otherwise there is nothing to trace back when the counts do not match.
Back to that backup list. What I finally handed over was two hundred and five names without extensions, with a line beside it reading "312 raw records, duplicate names merged", which kept my manager's question of what was stored separate from operations' question of whether every file was stored. Whether to deduplicate, whether to keep extensions, and how to treat lines with a trailing slash: those three decisions shape the result more than which tool you pick.