padth - 2014-02-21

I've had the same problem with renaming files with WinSCP. Instead of doing a rename() it does a link()/unlink() causing minidlna to not pickup the new filename.

I looked into doing an 'st.st_nlink > 1' check like suggested, however the unlink() is performed before minidlna gets a chance to stat() the file.

I've been looking at the inotify API and I haven't found any clean way to tell the difference between an IN_CREATE event sent because a new file has been opened for writing (i.e. currently being copied into the directory) and a new link that's been created to an existing file.

As a workaround I included the IN_CREATE event to the events that adds new files. This has the potential to add files that haven't been completely written (although in my testing the 'st.st_size > 0' check was sufficient to prevent this.) If that happens, the file will be added correctly when the IN_CLOSE_WRITE event is sent.

Not an ideal solution, but I'll leave this here in case someone else has issues with picking up hard links and can live with potentially adding incomplete files.

diff -rupN minidlna-1.1.1/inotify.c minidlna-1.1.1-pad//inotify.c
--- minidlna-1.1.1/inotify.c    2013-11-01 18:06:41.000000000 -0700
+++ minidlna-1.1.1-pad//inotify.c       2014-02-20 21:31:06.375955868 -0800
@@ -723,7 +723,7 @@ start_inotify()
                                                        inotify_insert_file(esc_name, path_buf);
-                                       else if( event->mask & (IN_CLOSE_WRITE|IN_MOVED_TO) && st.st_size > 0 )
+                                       else if( event->mask & (IN_CREATE|IN_CLOSE_WRITE|IN_MOVED_TO) && st.st_size > 0 )
                                                if( (event->mask & IN_MOVED_TO) ||
                                                    (sql_get_int_field(db, "SELECT TIMESTAMP from DETAILS where PATH = '%q'", path_buf) != st.st_mtime) )