linux symbolic links issues - with logs

[ReSearchIT Eng]

Hi,

Sorry for re-posting, I am adding some logs this time, to explain better.

First of all, congratulations for the project.

I am trying to make the app reuse the already existing folders with pictures. For this, I need to use some symbolic links (Linux).

It is able to see the pictures, but apparently it enters an infinite loop, as it keeps on creating cache and removing them again and again.

From my investigation, it might be due to the fact that the photo path is read as the actual link name, while cache path created by reading the link source.

What I mean:

The app is set to look under: /opt/picapport/photos/, and in there, it

will find links to the "mnt" path(, as well as the "selected" subfolder).

/opt/picapport/photos/170318-25 -> /opt/picapport/mnt/Pics/170318/selected/

The app starts processing the photos and writes cache under:

/opt/picapport/data/cache/opt/picapport/mnt/Pics/170318/selected/

Therefore, the app reads what is the actual path

(/opt/picapport/mnt/Pics/170318/selected/), and it used that as the subfolder to store the cache (/opt/picapport/data/cache/opt/picapport/mnt/Pics/170318/selected/).

I suspect that if the app would not detect/read the link source, but use the link name instead, it will would put the cache under

/opt/picapport/data/cache/opt/picapport/Pics/170318/ and it won't enter this infinite loop of removing and recreating the cache images again and again.

Here are the logs:

picapport_1  | DEBUG@ 21:08:15.835 CcJpegUtils.writeImage: Setting jpg compression quality to: 0.75
picapport_1  | DEBUG@ 21:08:16.010 CcJpegUtils.writeScaledImage:/opt/picapport/photos/170318-25/20170321_152925.jpg sem=0ms read=1170ms write=191ms
picapport_1  | DEBUG@ 21:08:16.011 DbWrapper.insertPhoto: /opt/picapport/mnt/Pics/170318/selected/20170321_152925.jpg
picapport_1  | DEBUG@ 21:08:16.035 DbWrapper.updateDirectory: /opt/picapport/photos/170318, 205
picapport_1  | DEBUG@ 21:08:16.038 DbWrapper.insertDirectory: /opt/picapport/photos/170318, 205
picapport_1  | INFO @ 21:08:16.039 PhotoCrawler.notifyStopCrawl:
picapport_1  | DEBUG@ 21:08:16.039 PicApportCmdQueue.queueCmd: statusmessage Crawler stopped
picapport_1  | DEBUG@ 21:08:16.039 PicApportCmdQueue.queueCmd: dbservice
picapport_1  | INFO @ 21:08:16.040 PicApportCmdQueue.execCmd: doCmd_statusmessage(Crawler stopped)
picapport_1  | INFO @ 21:08:16.040 PicApportCmdQueue.execCmd: doCmd_dbservice()
picapport_1  | DEBUG@ 21:08:16.040 PicApportCmdQueue.queueCmd: statusmessage DbWorker dbservice started
picapport_1  | INFO @ 21:08:16.041 PicApportCmdQueue.execCmd: doCmd_statusmessage(DbWorker dbservice started)
picapport_1  | INFO @ 21:08:16.042 DbWrapper.checkDirctoryForRemoval.remove: /opt/picapport/photos
picapport_1  | INFO @ 21:08:16.044 DbWrapper.checkDirctoryForRemoval.remove: /opt/picapport/mnt/Pics/170318/selected
picapport_1  | INFO @ 21:08:16.059 DbWrapper.checkPhotoForRemoval.remove: /opt/picapport/mnt/Pics/170318/selected/DSC_0330.jpg

Thanks in advance for looking into this.

[PicApport]

Hi,
the PicApport server scans the configured root folders recursively. The PicApport home directory (.picapport) should be separated from this also the cache and shadow directories if configured.

[E. Schreiner]

you can use the robot.filter.path.n parameter to filter some directorys (in your case the cache) for the crawler see http://wiki.picapport.de/display/PICE/PicApport-Server+Guide
Examples:
robot.filter.path.0=.?(?i\:private)
robot.filter.path.1=.?(?i\:[\\\\|/]books)

[ReSearchIT Eng]

Hi,

thanks for the quick reply.

cache folder is not part of the path by any means. That would have been an obvious issue and it would have removed also the cache of the pictures from non-linked folders.

I enabled the debug and it's pretty clear that the issue is related to the way java reads the local path. The part of java code which creates the photo cache reads the name of the symbolic link; while in the DbWrapper.checkDirctoryForRemoval.remove method it's reading the folder to which the symbolic link points to. Developer may need to either align both methods: for adding cache and removing, or use the isSymbolicLink&readSymbolicLink in the create cache method to translate to resolved path and use that one instead.

As the code isn't available, I cannot provide better suggestions.

[ReSearchIT Eng]

It was tried also with: foto.jpg.usecache=0. Some issue: picapport is adding and right after removing the pics from its db.

So, till there will be an alignment between the code that adding pics and the one to remove pics, picapport does not support linux/symbolic links.