Tag: command prompt

How to permanently disable Adobe’s PDApp.log (and others) on Windows or Mac

UPDATE (2020-02-16): Reports are coming in that this doesn’t work with the newest Adobe CC programs since they’re rotating the logs now. If this doesn’t work for you, it may be best to run a temporary file cleanup tool daily, such as Disk Cleanup included in Windows, CCleaner (warning: since Avast bought it, it’s a bit spammy now), or similar. Alternatively, if you are handy with such things, write a batch file that deletes the log files and add it to Task Scheduler as a task to run when you normally won’t be active on the machine.

UPDATE (2019-10-21): Adobe’s support has noticed this post and is attempting to have the bug behind this issue fixed. See the comments!

I recently discovered that Adobe’s Creative Cloud software left a massive pile of PDApp.log files in my temporary directories, as well as a few others such as CEP8-PPro.log and AdobeIPCBroker.log. These were taking up quite a bit of space, and I’ve looked up PDApp.log only to discover that some people have had serious issues with PDApp.log consuming all available free space on their drives after a while. One user reported having a 600GB log file! Needless to say, several people have asked how they can control these log files, but as usual, Adobe support and forum users offered no actual solutions.

I’m here with your solution!

Adobe log symlinks
What a sweet, sweet sight these are.

On Windows, you’ll need to open Task Manager and kill all Adobe processes to unlock the log files (not just stuff starting with Adobe, but also Creative Cloud processes and any node.exe instances they started) then open an administrative command prompt and type the following two commands:

cd %temp%
del PDApp.log
mklink PDApp.log NUL:

This goes to your temporary directory, deletes the PDApp.log file (if you get an “in use” error here you missed an Adobe process in Task Manager), and creates a file symbolic link to a special device called NUL: which is literally the “nothing” device. When the Adobe apps write to PDApp.log now, all writes will succeed (no errors) but the data will simply be discarded. You can repeat the delete/mklink process for any other Adobe logs you don’t want around anymore. Best of all, because symlinks on Windows require admin privileges to modify, the Adobe apps won’t rotate these fake log files out! Be aware that cleanup tools like CCleaner or Disk Cleanup may delete these links, so you may need to repeat these steps if you delete your temp folder contents with a cleaning tool. You may want to write a small batch file to run the commands in one shot if you like to delete temp files frequently.

On Mac OS (note: I haven’t tested this myself, but it should work) you should be able to kill all Adobe processes with Activity Monitor, then open Terminal, then type this:

ln -sf /dev/null ~/Library/Logs/PDApp.log

Linux/UNIX administrators will recognize this as the classic “redirect to /dev/null” technique that we all know and love. Since I have no way to test this, Adobe may rotate these links out, but you can use this command to lock down the symlink if it does:

sudo chown -h root:wheel ~/Library/Logs/PDApp.log

This will ask for your account password since it requires privilege escalation. This command makes the link owned by “root” which means normal user programs can’t rename or delete it, though they can still write through the link, so the trick will continue to work.

UPDATE: Some have asked what the purpose of the PDApp.log file is and whether it’s safe to do this. The answers are, respectively, “logs information for troubleshooting Creative Cloud installation problems” and “yes, absolutely.” If you’re not having installation issues, this log is just taking up space and wearing out your SSD. If you need to “re-enable it” it’s as simple as deleting the “decoy” links you made with these directions which will allow the logs to be created as if nothing ever happened.

Sort compressed tar archives to make them smaller… 20% smaller!

How would you like for your file archives to be 20% smaller, with just the tools every Linux distribution already provides and a little ingenuity?  Read on and see how I did it!

There was a folder “NESRen” that I wanted to pack up for archival, and I knew it contained many files that share the same data, minus a few changes here and there.  When packing them up and compressing them into a tarball archive, I knew that I will achieve better compression if these largely similar files are put side-by-side in the archive so that the repeated blocks of data “compress themselves away” and take up almost no space.  Unfortunately, the GNU “tar” command in nearly every Linux distribution packs up files and folders in the order that the underlying filesystem chooses, which is almost always unordered and not optimal for compression.

How do we make tar put files in an order which will compress better?  The answer is to use the tar -T option, which lets you feed tar a list of files to pack up.  The list is processed line-by-line, and each file is packed up in the order provided.  You can, for example, create a list of files with the “find” command, then hand-edit that list to be optimal, and pass the list to tar (you must use the –no-recursion option when creating the archive from this list since the “find” makes a recursive list already):

find folder_of_files/ > list.txt
vi list.txt
tar -c --no-recursion -T list.txt | xz > archive.tar.xz

In my case, however, the folder structure and naming conventions allowed for creative use of the “sort” command to arrange the files. Since there is one folder “NESRen” followed by a series of categorizations, followed by the file names themselves (i.e. “NESRen/World/Pinball (JU).nes”) I can do something like this to make all files with the same name sort beside each other, regardless of the name of the category directory (as “sort” with no options would do):

find NESRen | sort -t / --key=3 | \
  tar -cv -T - --no-recursion | xz -e > NESRen.tar.xz

The “-t /” tells sort to use a slash as a field delimiter, and –key=3 tells it to sort by the third field (NESRen is field 1, the folder is 2, the file is 3).  What kind of difference did that make for the size of my .tar.xz archive?  Take a look (-nosort archive created with “tar -c NESRen | xz -e > NESren-nosort.tar.xz”):

Size of each file in bytes:

212958664 NESRen-nosort.tar.xz
170021312 NESRen.tar.xz

Size of the original folder and each file in megabytes:

705M    NESRen
204M    NESRen-nosort.tar.xz
163M    NESRen.tar.xz

By sorting the files, I saw a 20.1% drop in archive size using the exact same compression method, with a total compression ratio of 23.1% versus the unsorted 28.9%.  That’s a huge difference!  If this were 70.5GB instead of 705MB and the data exhibited identical performance, the final archive would be 4.1GB smaller–nearly the entire capacity of a single-layer DVD-R in space savings, just by sorting the file names before compression.

Applying a similar sort-then-compress process to the packing of the “ext” version of the Tritech Service System, a 700KB reduction in the total size of the archive containing “ext” was seen.  Of course, this doesn’t help as much because the archive itself was already 32.7MB in size (700KB is only a 2.1% reduction) but it still means shorter load and boot times due to less overall data to handle.

Next time you’re packing a lot of stuff up, see if you can use these tricks to improve your compression ratio.