I also just discovered that if ASSP is restarted when these long files
exist in /tmp, Strawberry Perl dies when "Checking Directories"
On Tue, Sep 26, 2017 at 11:40 PM, K Post <nntp.p...@gmail.com> wrote:
> and FYI, for you windows folks, I remembered how to get rid of crazy long
> paths (more than 260 characters)
>
> 1) Create a new empty folder somewhere. Say c:\EmptyFolder
> 2) Launch command shell and do:
>
> robocopy c:\EmptyFolder c:\FolderYouWantToEmptyOut /purge
>
> This will copy the contents of EmptyFolder (nothing) to the folder you
> want to empty out and REMOVE all other files and folders because of the
> /purge switch.
>
> This doesn't solve the problem when ASSP extracts bad zips with these long
> filenames, but it gives us a temporary way, albeit a manual one, to remove
> the info from NTFS partitions until there's a fix or other method to stop
> this from happening (like telling me what config switch I have set wrong in
> ASSP).
>
>
>
> On Tue, Sep 26, 2017 at 11:23 PM, K Post <nntp.p...@gmail.com> wrote:
>
>> sorry, this is with 17244
>>
>> On Tue, Sep 26, 2017 at 11:22 PM, K Post <nntp.p...@gmail.com> wrote:
>>
>>> I'm getting errors like:
>>>
>>> Sep-26-17 23:00:19 Warning: got unexpected signal SEGV in Worker_1:
>>> package - Win32::Unicode::Dir, file -
>>> c:/strawberry/perl/site/lib/Win32/Unicode/Dir.pm,
>>> line - 80!
>>>
>>> Sep-26-17 23:00:29 Warning: try to terminate inactive/stuck Worker_1
>>>
>>> Sep-26-17 23:00:29 msg81131-14259 202.79.16.19 <
>>> spam...@outsidedomain.com> to: ouru...@domain.org error: unable to
>>> parse message for attachments - TERMINATED - possibly by MainThread on
>>> detected stuck - in package - main, file - c:\assp\assp.pl, line -
>>> 65368.
>>>
>>> It looks like we're getting slammed with attachments that contains java
>>> in zips.
>>>
>>> If I look in c:/assp/tmp I see folders like zip_2_1506481037
>>>
>>> If I try to delete the zip file, windows throws a warning that some
>>> filenames are too long for the recycle bin and that I'll need to delete
>>> permanently. if I say okay to that, the files still don't delete. If I
>>> try shift-deleting (permanent delete from the start), after confirming, I
>>> get "The source file name(s)are larger than is supported by the file
>>> system. Try moving to a location which has a shorter path name, or try
>>> renaming to shorter name(s) before attempting this operation."
>>>
>>> I also tried deleting from the command prompt, using rmdi /s and get:
>>>
>>> c:\assp\tmp>rmdir /S zip_1_1506481039
>>> zip_1_1506481039, Are you sure (Y/N)? y
>>> zip_1_1506481039\.10\EcarOcuhAyucu\UfirIcehUyucu\UliroCahayo
>>> ci\1152huu1od1ip9lln
>>> 2jel652vmqjojmggm16v37h5bsqfflen\ht1c8p19t61g5dl4as44uasaif6
>>> ib3l5iog39akos3hootq
>>> l6hklu7\94df36g2uliulse16f3qv7emo3r2stta4fmldjg35movenhlt9b4
>>> jn4jjqso5uhfakf12isg
>>> 4dpdultgot - The system cannot find the path specified.
>>>
>>> I'm sure I can get these deleted using another tool, but I'm wondering
>>> what we can do with ASSP to prevent this from happening again. If a zip
>>> has crazy long folder or file names, I say we reject it. The question
>>> becomes if ASSP can somehow determine that without first saving the
>>> extracted data to tmp (And thereby making it hard to delete).
>>>
>>> Suggestions?
>>>
>>>
>>
>
------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
_______________________________________________
Assp-test mailing list
Assp-test@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/assp-test
