Rich;
Possible to open output file exclusively? If -in and-out are opened
exclusively, the second open of the same file would fail. May be portable.
Allan
--
misspelled on my iDevice ; +1-424-242-2668
> On Jul 26, 2014, at 12:50, "Rich Salz via RT" wrote:
>
> i hate this kind of thing. The
On 2007.04.25 at 01:55:23 -0700, David Schwartz wrote:
>
> > For example, if we are running under Unix-style kernel, we can make
> > stat calls on both files. And if both st_dev and st_ino fields of
> > the resulting stat structures are same, we should consider files same.
>
> Why? Suppose the f
> For example, if we are running under Unix-style kernel, we can make
> stat calls on both files. And if both st_dev and st_ino fields of
> the resulting stat structures are same, we should consider files same.
Why? Suppose the filesystem internally uses inodes larger than the st_ino
field. Is it
On 2007.04.20 at 11:57:35 -0700, David Schwartz wrote:
>
> > On 2007.04.19 at 11:59:39 -0700, David Schwartz wrote:
> >
> > > This is not nearly as simple as you might think. Are 'foo.txt'
> > and 'Foo.txt' the same file? What about 'directory/file.txt' and
> > 'symlink/file.txt'?
> > >
> > > I d
> On 2007.04.19 at 11:59:39 -0700, David Schwartz wrote:
>
> > This is not nearly as simple as you might think. Are 'foo.txt'
> and 'Foo.txt' the same file? What about 'directory/file.txt' and
> 'symlink/file.txt'?
> >
> > I don't see how you can do this without making assumptions about the
> > se
Hi,
> I don't see why these assumptions cannot be done at compile time.
> There exists few different filesystem semanctics:
>
> Unix one,
> DOS/Windows one,
> VMS (versioned) one.
How do you know which one to use? In our networked world it's difficult
to know what kind of filesystems you
On 2007.04.19 at 11:59:39 -0700, David Schwartz wrote:
> This is not nearly as simple as you might think. Are 'foo.txt' and 'Foo.txt'
> the same file? What about 'directory/file.txt' and 'symlink/file.txt'?
>
> I don't see how you can do this without making assumptions about the
> semantics of t
> I have been using openssl for some personal home-use encryption, and
> recently overwrote an input file while using openssl bf accidentally
> because bash's autocompletion put in the input file's name when I
> started typing the same name (minus bf at the end) for the output and I
> careless
