[DCMEE-826] Compression service may fail on images that don't have hex based filenames - images stored using private transfter syntax specifying Retrieve URI instead of pixel data Created: 30/Apr/08  Updated: 28/Nov/18  Resolved: 28/Nov/18

Status: Closed
Project: dcm4chee
Components: None
Affects versions: dcm4chee-2.13.3
Fix versions: None

Type: Improvement Priority: Minor
Reporter: Justin Justin Assignee: Gunter Zeilinger
Resolution: Won't Fix Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original estimate: Not Specified
Environment:

Windows XP, PostgreSQL, dcm4chee 2.13.3


Testing Assignee: Peter Heiles
Sprint:

 Description   

Images were migrated to dcm4chee using dcmsnd and specifying the -fileref argument to send using private transfer syntax (1.2.40.0.13.1.1.2.4.94) to only send file references rather than pixel data. The migration worked splendidly. Once complete, I marked the migrated filesystem to RW so that JLSL compression would be applied via the compression service. An error occurred because the compression service assumes the filename is in the same format as natively generated by dcm4chee (ex. 70C6B59E) where as the migrated filenames were based on sop iuid with a dcm extension (ex. 1.2.3.dcm).

2008-04-30 10:06:51,674 ERROR -> (Timer-2) [CompressionService] Can't compress file:F:\ImportedImages\HospitalA\1.2.840.111111111111111111\1.2.840.2222222222222222222\1.2.840.33333333333333333333.dcm
java.lang.NumberFormatException: For input string: "1.2.840.33333333333333333333.dcm"
	at java.lang.NumberFormatException.forInputString(NumberFormatException.java:48)
	at java.lang.Long.parseLong(Long.java:412)
	at org.dcm4chex.archive.mbean.CompressionService.doCompress(CompressionService.java:355)
	at org.dcm4chex.archive.mbean.CompressionService.checkForFilesToCompress(CompressionService.java:290)
	at org.dcm4chex.archive.mbean.CompressionService$1.handleNotification(CompressionService.java:128)
	at sun.reflect.GeneratedMethodAccessor4.invoke(Unknown Source)
	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
	at java.lang.reflect.Method.invoke(Method.java:597)
	at org.jboss.mx.notification.NotificationListenerProxy.invoke(NotificationListenerProxy.java:153)
	at $Proxy11.handleNotification(Unknown Source)
	at javax.management.NotificationBroadcasterSupport.handleNotification(NotificationBroadcasterSupport.java:257)
	at javax.management.NotificationBroadcasterSupport$SendNotifJob.run(NotificationBroadcasterSupport.java:322)
	at javax.management.NotificationBroadcasterSupport$1.execute(NotificationBroadcasterSupport.java:307)
	at javax.management.NotificationBroadcasterSupport.sendNotification(NotificationBroadcasterSupport.java:229)
	at javax.management.timer.Timer.sendNotification(Timer.java:1234)
	at javax.management.timer.Timer.notifyAlarmClock(Timer.java:1203)
	at javax.management.timer.TimerAlarmClock.run(Timer.java:1286)
	at java.util.TimerThread.mainLoop(Timer.java:512)
	at java.util.TimerThread.run(Timer.java:462)

The problem is the following code that attempts to generate a new filename:

	        destFile = FileUtils.createNewFile(srcFile.getParentFile(), (int) Long.parseLong(srcFile.getName(), 16)+1);

Could a more generic method of generating a filename be used? Or perhaps could there be a configuration that would just append some suffix to the original filename?


Generated at Tue Apr 16 19:17:21 UTC 2024 using Jira 1001.0.0-SNAPSHOT#100250-rev:9c61b78796b51839636b0c22f7f9f2138328d1a0.