Folder listing dialog creates file in "C:\Windows\System32"

Help & Support
1
  • Open the "Print Folder Contents" dialog by running Print FOLDER using the > quick key.
  • Choose "File" and paste the filename di9hyegop4.txt.
  • Press "OK".
    • Strange: A UAC elevation dialog appears on the secure desktop.
  • Search for the file di9hyegop4.txt using Everything or by other means.
    • Bug: An empty file with that name landed in C:\Windows\System32. I had expected the file to be created in the current source display folder, and that it wouldn't be empty.
2

If you specify just a name without a path, the file is going to go into the program's current directory, which is System32.

Specify a full path.

3

Nothing in the dialog lets you expect this target folder. Also, as I said: The file there was empty (0 bytes), even though I confirmed the elevation.

It gets worse: Earlier today, I worked with a certain folder in another lister. Now, the lister was long closed and I was working on a different drive. When I ran the dialog with just a filename again, the file was created in the folder from earlier in the day (the file wasn't empty, and I have no idea what made DOpus change its working directory earlier). This is just random behavior from the user perspective, wildly creates artifacts where they don't belong, and may even amount to a breach of privacy.

A filename without a path should use the current destination folder path with source folder as fallback, similar to using quick key > to run cmd.exe /K type source_display_file.txt, e.g., correctly prints that file's contents to the console.

This experience also reveals that problems like privacy breaches may also happen in other contexts, if they have yet unidentified bugs. If DOpus generally changed its process's working directory to that of the current destination/source file display, possible consequences of yet unidentified bugs would be alleviated.

4

Opus never changes its current directory itself, but she'll extensions and other third-party software loaded into our process might. The whole concept of a process-wide current directory is unsuitable for modern systems. That's why you should always specify a path.

5

As this example shows, there can be places where DOpus de facto writes data to inappropriate places. What I wrote about setting the working directory was just meant as a general means to alleviate yet unknown bugs that may exist elsewhere in DOpus and lead to privacy breaches (like writing private data into a folder that will be shared without you checking it again before that, because you don't expect such a bug).

If you just don't want to accept a filename-only path in the "Print Folder Contents" dialog to write it to the destination/source folder (which is a separate matter to the previous paragraph), please disallow filename-only/non-absolute paths instead of just writing the file somewhere! This should never happen.

1 Like
6

"just writing a file 'somewhere' " is a bad thing. The file manager not the end user should provide this safety/security feature. We all need a little help for/protection from ourselves, sometimes.

1 Like