Hi Lars,

On Fri, Aug 29, 2014 at 7:26 AM, Lars Eggert <[email protected]> wrote:

> error: Unable to truncate() files not created by this job:
> /@tupjob-1291/usr/home/lars/tup/src/lua/lcode.c
>

Hmm, I get this error too. However, it seems to be something in the FUSE
lib that causes it to call truncate() on files that are opened O_RDONLY.
I'm not sure why it does that, but you can also see it using fusexmp (ie:
without tup in the picture).

t1$ ./fusexmp -f -d tmp
t2$ cd tmp/home/marf
t2$ cat ok.c

In terminal 1 I see:

unique: 13, opcode: LOOKUP (1), nodeid: 5, insize: 45, pid: 36569
LOOKUP /usr/home/marf/ok.c
getattr /usr/home/marf/ok.c
   NODEID: 6
   unique: 13, success, outsize: 136
unique: 14, opcode: OPEN (14), nodeid: 6, insize: 48, pid: 36569
open flags: 0x0 /usr/home/marf/ok.c
   open[0] flags: 0x0 /usr/home/marf/ok.c
   unique: 14, success, outsize: 32
unique: 15, opcode: GETATTR (3), nodeid: 6, insize: 40, pid: 36569
getattr /usr/home/marf/ok.c
   unique: 15, success, outsize: 112
unique: 16, opcode: READ (15), nodeid: 6, insize: 64, pid: 36569
read[0] 128 bytes from 0 flags: 0x0
   read[0] 128 bytes from 0
   unique: 16, success, outsize: 144
unique: 17, opcode: SETATTR (4), nodeid: 6, insize: 128, pid: 36569
*** truncate /usr/home/marf/ok.c 128
getattr /usr/home/marf/ok.c
   unique: 17, success, outsize: 112
unique: 18, opcode: RELEASE (18), nodeid: 6, insize: 64, pid: 36569
release[0] flags: 0x0
   unique: 18, success, outsize: 16

(truncate() highlighted with ***). Even though I am just using 'cat', which
opens the file with O_RDONLY, FUSE decides to call truncate() on the file
(with the correct file length, at least). So FUSE is opening the file
read-only, and then writing to the file! Tup doesn't have any control over
that unfortunately, but it complains about it since it is obviously wrong.

Maybe you can check with someone on FreeBSD's FUSE team to find out why it
would be doing that? Or maybe there is an option we can pass to FUSE to get
it to stop doing it? I don't know why calling truncate in this case would
be useful - it seems like a bug to me. Off-hand I can't think of a good
workaround to implement in tup - we can't just disable truncate() since
there are valid cases for it.


> * 1) src/lua: CC lcode.c
>  *** tup errors ***
> tup error: Unspecified output files - A command is writing to files that
> you didn't specify in the Tupfile. You should add them so tup knows what to
> expect.
>  -- Unspecified output: src/compat/freebsd.h
>

I think this is really the same error as above - tup will track a
truncate() call as a write (output) access, and then complains about it
because it shouldn't be writing to that file. So I think if we track down
the truncate issue, this will go away as well (I hope :).

-Mike

-- 
-- 
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.

Reply via email to