Items longer than 256 characters fail

[GoogleCodeExporter]

What steps will reproduce the problem?
1. Run any ppss where an item is longer than 256 characters
2. Any item longer than 256 characters is always seen as locked, causing it to 
be skipped.

What version of the product are you using? On what operating system?

ppss Version 2.97

Linux 2.6.18-274.12.1.el5 #1 SMP Tue Nov 8 21:37:35 EST 2011 x86_64 GNU/Linux

I have included a patch that fixes the problem by splitting long filenames into 
directory hierarchies of short file names. It's an ugly hack, and you're 
probably better off using MD5 instead, but at least it works.

Original issue reported on code.google.com by r...@thompsonclan.org on 19 Jan 2012 at 6:48

Attachments:

• ppss-longitems.patch

[GoogleCodeExporter]

Hi RCT, 

Thanks for your patch, but it breaks some core PPSS functionality. You are 
using mkdir -p. However, the mkdir command is used to make locking atomic. 
using -p the locking is no longer atomic. This solution is thus not working.

I do think that the actual lock file should be an MD5 hash, only the log file 
should be a regular file name if people want this. 

In what kind of situation are you running into the 256 character limit?

Original comment by Louwrentius on 29 Jan 2012 at 10:01

[GoogleCodeExporter]

My usage of ppss is generating a large number of shell commands and piping them 
into  "ppss -M -c 'sh -c ' -f -". The commands are frequently longer than 256 
characters.

Original comment by r...@thompsonclan.org on 29 Jan 2012 at 10:22

[GoogleCodeExporter]

The solution to this is not patching PPSS but to create a small script.

I guess you are creating a list of commands that are exected by sh. However, 
you should not do that. 

Create a list of unique items to be processed. Create a script that contains 
the command executed and that expects the item as an argument. Then your 
problem is solved.

If you can generate a lot of shell commands, you can probably also generate a 
list of unique items to be processed.

Original comment by Louwrentius on 30 Jan 2012 at 12:50

• Added labels: Priority-Low
• Removed labels: Priority-Medium

[GoogleCodeExporter]

Please note that the explanation as described is also documented in the wiki.

Original comment by Louwrentius on 30 Jan 2012 at 12:50

[GoogleCodeExporter]

Original comment by Louwrentius on 9 Feb 2012 at 7:49

• Changed state: Invalid

[GoogleCodeExporter]

If anything, it might be prudent to eventually implement a check for the 
maximum supported file name length by progressively attempting to create longer 
and longer file names until one fails. Then, check if any of the inputs are 
longer than that and raise an error. Because as it works now, it just fails 
silently. But this would be low priority.

An even cheaper short-term stopgap would be to just warn if any input is 256 
characters or longer.

Original comment by r...@thompsonclan.org on 9 Feb 2012 at 9:18