Activity for Phil Hudson
-
Phil Hudson created ticket #4
di silently succeeds with malformed $DI_ARGS
-
Boy do I feel stupid. I just realized that my DI_ARGS was missing '-f' before the format specifier string, and that it has been missing for many years. Sorry for the noise and please close.
-
Thanks for the suggestion, but no, I don't think that will suffice, since I already have M in my $DI_ARGS (sMbuv1t, to be precise). Before I made the edit documented in my second comment above, then recompiled and reinstalled, my listed mountpoints were all truncated to 15 characters. Now they are not. For mountpoints under /run/media/phil/, (that is, those mounted automatically or by the udisk subsystem on Linux), all that was visible in the mountpoint field was precisely /run/media/phil, which...
-
For anyone else who wants a quick-and-dirty fix for this now, change the hard-coded literal 15 at line 1126 of display.c to whatever you want.
-
I used an external editor to complete the above and it looks like the final text, which did display correctly in the edit field before I submitted it, was nevertheless truncated where I invoked the external editor, so apologies for that, and I'll stick to in-browser editing now. It should go on to say: "... or the facility to pipe the mountpoint string through an external process such as a shell script before insertion, or both. Thank you."
-
Make mountpoint field customizable
-
RFE: More/better notification
-
New switches: --one-and-done and/or --browse
-
Good check , but I never use FTP, only SSH (and sftp/scp/rsync). I'm pretty sure it wasn't an integrity issue because clients could and did sync down from the previous server correctly. But thanks for thinking of everything possible. I really appreciate you making so much effort to help me. On Wednesday, 14 August 2019, Davide Marchi danjde@users.sourceforge.net wrote: ..also checks the integrity of the files (db included)! If you have upload via ftp, they may have suffered damage. Try to upload...
-
Set up on a desktop machine. Still errors, but now no longer includes the contents of deletefile.php. Instead, I now get an error alert reading: There's been some kind of problem deleting a file to the HTTP server. The error message is [FILE_WASNT_DELETED]. Now /v/l/a/error.log shows: PHP Warning: unlink(./upm.db): Permission denied in /var/www/upm/deletefile.php on line 46 FIXED FIXED FIXED! Changed owner of /v/w/upm recursively to www-data: (as previously on the other host) and SYNC UPLOAD NOW...
-
Tried it, didn't work. I changed the whole of /var/www (recursively) to www-data:www-data. Same symptoms. Are we stuck? If so I'll try to set up apache on a desktop machine and run it on demand. On 12/08/2019, Davide Marchi danjde@users.sourceforge.net wrote: ..but have you try to excute: chown -R www-data:www-data /upm ? And anyway the problem seems on deletefile.php, check out this ;-) Sync upload error Sent from sourceforge.net because you indicated interest in https://sourceforge.net/p/upm/discussion/517033/...
-
I appreciate that. I did not have the ErrorLog directive in my vhost config. I've added it. Sorry, still just the same GET and POST entries in /v/l/a/other_vhosts_access.log, and nothing in /v/l/a/error.log (except the usual couple of entries for the 'graceful' restart I did after editing the vhost config). This is after four attempted upload syncs, with each resulting in the same client-side behaviour documented in my initial report (error alert containing the full text of deletefile.php). /var/www/upm/upload.php...
-
OK, thanks. Any ideas on further diagnostic steps I can take? On 11/08/2019, Davide Marchi danjde@users.sourceforge.net wrote: I do see libapache2-mod-security2 available in the repo. Do I need to install it? No! Sync upload error Sent from sourceforge.net because you indicated interest in https://sourceforge.net/p/upm/discussion/517033/ To unsubscribe from further messages, please visit https://sourceforge.net/auth/subscriptions/ -- phil.hudson@iname.com PGP/GnuPG ID: 0x887DCA63
-
I do see the following in /v/l/a/other_vhosts_access.log: <server.host:port> <client ip=""> - - [10/Aug/2019:01:08:35 +0100] "GET /upm/upm.db HTTP/1.1" 200 20235 "-" "Jakarta Commons-HttpClient/3.0" <server.host:port> <client ip=""> - - [10/Aug/2019:01:08:35 +0100] "POST /upm/deletefile.php HTTP/1.1" 200 2506 "-" "Jakarta Commons-HttpClient/3.0"</client></server.host:port></client></server.host:port> On 09/08/2019, Davide Marchi danjde@users.sourceforge.net wrote: Are you using mod_security (1)?...
-
Thanks Davide. I don't remember using mod_security on the old server; I have done nothing to install or configure it on the new one. I do see libapache2-mod-security2 available in the repo. Do I need to install it? Nothing appears in either /v/l/a/error.log or /v/l/a/access.log when I try to perform a db upload. There is no /v/l/a/modsec_audit.log. I hope this is helpful. On 09/08/2019, Davide Marchi danjde@users.sourceforge.net wrote: Are you using mod_security (1)? Have you tried (while performing...
-
Desktop is the only client I have with an updated DB needing sync. On 08/08/2019, Davide Marchi danjde@users.sourceforge.net wrote: Is this isssue from mobile, desktop or both? Sync upload error Sent from sourceforge.net because you indicated interest in https://sourceforge.net/p/upm/discussion/517033/ To unsubscribe from further messages, please visit https://sourceforge.net/auth/subscriptions/ -- phil.hudson@iname.com PGP/GnuPG ID: 0x887DCA63
-
I had HTTP sync working for years, then my server died. I thought I had everything re-configured on a new server but I must be missing something. I can download a more-recent database to any client (desktop or Android) but I can't upload an updated one (desktop). I get an error alert saying: "There's been some kind of problem deleting a file to (sic) the HTTP server. The error message is[" followed by the contents of deletefile.php. I can't see anything in the apache logs that will help. uname -a...
-
After years of happy use, I have a new requirement: a command-line interface. How...
1