Work at SourceForge, help us to make it a better place! We have an immediate need for a Support Technician in our San Francisco or Denver office.

Close

#3795 Permission bit corruption (two-stage is off)

closed-works-for-me
5
2013-04-08
2013-04-05
Modulok
No

Before anyone says to turn off the two-stage save, I've already done that. I'm
using jEdit 5.0.0 on Java 1.6.0_30 on Windows 7. Vanilla install, no plugins.
(I renamed my jedit prefs folder specifically to test the bug below.)

The problem

When editing a file on a remote samba server, jEdit adjust the file
permissions after each save. It removes the user execute bit. **I have
already turned off the two-stage save.** (See the inode number below.)

The problem is not samba, or the file server as other editors I tried work
correctly. The correct behavior would be leaving the file permissions
exactly as they were.

Steps to reproduce

1. Turn off the two-stage save. Utilities->Options->Saving & Backup.
Un-check Two-stage save. Click Apply/Ok.

2. Make a file on the remote server::

touch foo.txt

3. Set the permissions to include a user-execute bit::

chmod 777 foo.txt

4. Look at the file's permission. Notice the user-execute bit and inode number::

ls -lhi foo.txt
118582097 -rwxrwxrwx 1 Modulok Modulok 0B Apr 5 02:21 foo.txt

5. Open the file in jEdit. Edit the file and then click File->Save.
6. Bam! jEdit turns off the user-execute bit::

ls -lhi foo.txt
118582097 -rw-rwxrwx 1 Modulok Modulok 2B Apr 5 02:22 foo.txt

The expected result was the permission bits to remain exactly as they were.

Notice the inode number is the same. (Again, the two-stage save is turned off.)
I tried this same test with Notepad. Notepad correctly left the permission bits
as they were. I also edited the file on the server itself with nano, it
correctly left the permissions as they were. The file extension doesn't seem to
matter. (I tried a .txt file and .py file. Same result.)

Can anyone fix this?
-Modulok-

Discussion

  • I tried to reproduce but failed. My steps:

    1. starting clean jedit 5 with new settings dir (-settings=a_non_exist_dir). I also have Win7 64 jre 1.6.30
    2. prepare the file on samba share (debian)
    3. checked 777 - ok
    4. edited - yes, file spoiled, because of 2-stage save; however I got -rwxrw-rw-
    5. turned off 2-stage
    6. works ok, preserves 777
    7. tried different backup settings and always 777 preserved

    Please verify:
    - the version you use, because there were fixes just before 5 release
    - starting with clean settings

    Related fixed bug: 1803073
    http://sourceforge.net/tracker/index.php?func=detail&aid=1803073&group_id=588&atid=100588

     
  • Modulok, I still have no idea what causes unwanted behaviour in your installation. But I have some more thoughts:
    1. rm a; touch a - preserves the inode, while you seem to think that is changes it
    2. Please try to run the following macro. It basically does what save does, but it's code is absolutely clean. Test how does it affect the permissions. The next step could be to write a simple java application and test it outside jedit.
    3. To make me absolutely calm, please post the line with "jEdit version" from your activity log. Your report is very professional, but that's the point I'd like to double check.

    The macro:

    f = new File("/tmp/a");
    os = new FileOutputStream(f);
    os.write('a');
    os.close();

     
    • assigned_to: nobody --> jarekczek
    • status: open --> pending-works-for-me
     
  • Modulok
    Modulok
    2013-04-07

    Update:

    I don't think it's jEdit... (My apologies for the premature bug report.) But
    apparently I'm not alone:

    http://superuser.com/questions/541270/strange-permission-changes-when-saving-file-on-a-samba-partition-from-a-windows

    I tried it with jEdit 5.0.0 on another Windows 7 machine against the same file
    server and could not reproduce the bug. jEdit behaved correctly preserving all
    file permissions.

    You'd think "Aha! server configuration error," but it only happens with certain
    editors. For example, my Wordpad shows the bug, but my Notepad does not. (The
    later is why I figured it had to be a jEdit bug and filed the report.)

    I'll look into this deeper... but I'm pretty sure jEdit is off the hook ;)

    Sorry for the noise.
    -Modulok-

     
  • Modulok
    Modulok
    2013-04-07

    • status: pending-works-for-me --> open-works-for-me
     
  • Interesting link, no answers yet. Please keep us informed!

    You may still try running simple applications written in languages C and Java (also BAT, Vbscript) on the vulnerable station. If you want my help here, please contact me privately. I'm interested in the cause and solution for this problem.

     
    • status: open-works-for-me --> closed-works-for-me