It works with the rule : database.db |> sqlite3 file:%f?mode=ro .d > %o |> database.db.dump
on my Ubuntu 14.04 machine. Note that URI processing has to be enabled in the build of sqlite3 (the program), so there is a (small) possibility that your version has it disabled. On 18 March 2015 at 12:49, Stephen Irons <[email protected]> wrote: > > On 17 March 2015 at 13:03, Ahmad Khayyat <[email protected]> wrote: > >> On Tue, Mar 17, 2015 at 12:36 AM, Freddie Chopin < >> [email protected]> wrote: >> >> >>> Tup has some limitations - you encountered several of them at once: >>> - files in hidden directories are not tracked as dependencies, >>> - files cannot be written to hidden directories, >>> - you absolutely cannot read and write to the same file. >>> >> >> [... >> >> ] >> >> The third one is fundamental to the way tup works and this can never be >>> changed (probably <: )... >>> >> >> In fact, I think I have been somewhat saved by the first two >> limitations, in the sense that my Tupfile would do something useful and >> generate the desired outputs at all, precisely because it is ignoring the >> sqlite file, which is problematic because it appears as if it's being >> written to no matter how it's actually being used. My trouble started when >> I tried to make the sqlite file visible to tup. >> >> Note that nowhere in my Tupfile am I trying to write to the sqlite file. >> I think that this is how sqlite works; it always opens the file for both >> read and write. In fact, my version control tool tells me the sqlite files >> does not change. >> >> If this is true, then I think this is perhaps a fourth limitation? If a >> file is being opened for writing, but is never actually being written to, >> does tup require it to be listed as output? I don't know of other >> applications that exhibit this behavior, but AFAICT, sqlite is one. So an >> sqlite file can never be used as input in tup, because it always behaves >> like an output, and it can't be both. >> >> >> > When sqlite3 starts, it opens the file using the flags create and > read-write mode, to ensure that it creates-and-opens the file atomically > (in case a different process tries to access the same database file at > about the same time). You can see this if you run 'strace sqlite3 > database.db .quit' (which does nothing to the database, but will create the > file if it does not exist). > > sqlite3 (the program) assumes that you are going to modify the database, > rather than trying to cope with atomically changing the file-mode from > read-only to read-write if you actually try to modify the file. > > sqlite3 (the library) has support for opening the database file in > read-only mode; you then cannot modify the database. > > sqlite3 (the program) supports this if you use the 'URI' method of > specifying the database file. > > Instead of using the database file name 'database.db', try the URI > 'file:database.db?mode=ro'. > > Try 'strace sqlite3 file:database.db?mode=ro .dump', and you will find > that it cannot find a file called 'file:database.db?mode=ro', then later > opens the database file using the flag read-only. It does not try to create > the file if it does not exist. > > Stephen Irons > > -- -- tup-users mailing list email: [email protected] unsubscribe: [email protected] options: http://groups.google.com/group/tup-users?hl=en --- You received this message because you are subscribed to the Google Groups "tup-users" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. For more options, visit https://groups.google.com/d/optout.
